Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[John Moreno]

Russ Allbery wrote:

>> I'm sorry to hear that - if you have fixed 16c then the only thing
>> that's out of place is 7c and this can result in either the users server
>> not accepting the article or other servers not propagating their
>> messages.
>
>I find this highly unlikely, but I'm willing to be convinced that I'm
>wrong if you have some evidence to support this statement.

Just a bit of a personal investigation.

I use a offline reader and have about 8,000 articles downloaded (off a 
bit because of cross posting).

I just ran a perl script to see what the references lines looks like.

Out of all those articles I have two (2) which have a references line 
length  over 998bytes (1013 & 1015).  34 with over 900 bytes. And more 
than half of them are less than 250 (4278).

In a way this (GNKSA 7c) is a acknowledge of a current situation and a 
attempt to get newsreaders to use a LONGER references line (and not to 
cut out the reference to the first article).

-- 
John Moreno

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[John Moreno]

[Getting back to this a little latter]

Russ Allbery wrote:

>Furthermore, should Gnus comply with 7c, it would be in *violation* of
>what's likely to become the new news standard, given that it will almost
>certainly be recommended that References *never* be truncated if it can be
>avoided.

Are you talking about the USEFOR list and Simon Lyall's last proposal 
(Draft 0.6 References)?

If so then no, they would probably be implemented differently but they 
don't have to be.  The GNKSA isn't as strict as the USEFOR proposal but 
they don't conflict - a program that is compliant with the USEFOR draft 
can be compliant with the GNKSA.  Also (and this is something I should 
probably forward to USEFOR) Simon's proposal allows agents to keep just 6 
references, which IMO will result in agents doing just that.  I prefer 
the 1-3 rule and not to truncate before 998 - but a 3-3 rule and not to 
truncate before 998 would be just fine.  It'd cause the GNKSA to be out 
of sync but I imagine if the USEFOR draft is ever finished that the GNKSA 
will be updated.

Before replying to this I read all of the USEFOR messages with References 
in the body - and there's something which I think has been missed out on: 
In the case of the References header the MINIMUM is probably going to be 
the defacto MAXIMUM.  Not in the sense as some people seem worried about 
(not being able to handle longer without crashing) but, but in the sense 
that this is going to be the type of output newsreaders are going to do.

-- 
John Moreno

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[Lars Magne Ingebrigtsen]

Russ Allbery <rra@stanford.edu> writes:

> ;; Delete anything between the current point and the signature (defined as
> ;; the block starting with "-- " at the beginning of a line.  *Extremely*
> ;; useful for killing quoted text.
> (define-key message-mode-map "\C-cz" 'rra-kill-to-signature)
> (defun rra-kill-to-signature ()
>   "Deletes all text up to the signature."
>   (interactive)
>   (save-excursion
>     (push-mark (point) t t)
>     (re-search-forward "^-- ")
>     (forward-line -1)
>     (kill-region (mark) (point))))

Seems like a useful command to me.  What keystroke should it be bound
to?  The `C-c C-LETTER' keymap is starting to get rather full...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[John Moreno]

Russ Allbery wrote:
> John Moreno <phenix@interpath.com> writes:

>> Also note that this should allow any one message to have references
>> going back between 30-40 messages.
>
>Assuming airnews or Pine message IDs, about 15-20 is more accurate.  But
>threading becomes easier the fuller the References header is.

True on both counts, but is 10-20 messages in between needing to resample 
the header a excessively low number?  I frequently see (although not as 
frequently as messages with no refs) messages with only 1 item, which is 
ALLOWED under 1036.  I also know of several threads with plenty of 
traffic which have been going on for months - the references header in 
these messages if including every single message-id would be in the 10s 
or 100s of k range.  It's got to be snipped sometime, ~1k seems like a 
good enough place to me.

>> I'm sorry to hear that - if you have fixed 16c then the only thing
>> that's out of place is 7c and this can result in either the users server
>> not accepting the article or other servers not propagating their
>> messages.
>
>I find this highly unlikely, but I'm willing to be convinced that I'm
>wrong if you have some evidence to support this statement.

I have anecdotal evidence only - I have talked to people who have had 
their articles rejected from their servers for exactly this reason (long 
headers) and upon examination it was the references header which was the 
problem (and one case where it wasn't the references header it was 
instead the fact that the last header field was missing a cr and so the 
server thought part of the body was part of the header). I'll admit that 
I don't have any evidence of servers not passing along messages because 
of this.  I'll also admit that upon testing it was possible to get the 
messages posted even with the long header if the header was wrapped using 
the "cr space" format.

-- 
John Moreno

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[John Moreno]

Kai Grossjohann wrote:

>>>>> On Sun, 4 Jan 98, John Moreno said:
>
>  John> It is a attempt to have software FACILITATE using the correct
>  John> etiquette.  It means that software should provide a method
>
>I can see the advantage of having the option of marking a part of a
>message then hitting the reply button then the user agent inserting
>only that part as quoted text.  Rather than the user always getting
>everything at first and then having to cut away the rest.
>
>While this might be useful, I think it is not an important feature.

It's considered important only in the sense of having features that 
encourage the user to do the right thing - it is NOT a requirement for 
getting the GNKSA.

All of the 'Soft' requirement are features which while considered very 
good and useful and guides the user into correct behavior, may not be 
appropriate for all users or newsreaders.  For instance if most of your 
time on the net was spent in alt.fan.warlord this wouldn't be a very good 
feature for you.

-- 
John Moreno

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[Kai Grossjohann]

>>>>> On Sun, 4 Jan 98, John Moreno said:

  John> It is a attempt to have software FACILITATE using the correct
  John> etiquette.  It means that software should provide a method
  John> which allows the human to do the right thing quickly and
  John> easily.

I can see the advantage of having the option of marking a part of a
message then hitting the reply button then the user agent inserting
only that part as quoted text.  Rather than the user always getting
everything at first and then having to cut away the rest.

While this might be useful, I think it is not an important feature.

kai
-- 
Kai Grossjohann, Informatik VI        grossjohann@ls6.cs.uni-dortmund.de
Uni Dortmund, D-44221 Dortmund        http://ls6-www.cs.uni-dortmund.de/
                                      Vox +49 231 755 5670, Fax -2405
I like both kinds of music.

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[John Moreno]

Kai Grossjohann wrote:

>>>>> On 04 Jan 1998, Russ Allbery said:
>
>  GNKSA>     10e  Does not let the user indicate which part to followup to
>
>  Russ> This is nonsensical.  In the entire time that I've been
>  Russ> reading and posting to Usenet, I've never had a need for any
>  Russ> such thing, or even have any coherent idea how one would *do*
>  Russ> such a thing.  It sounds to me like a broken attempt to encode
>  Russ> etiqutte that requires human intervention and forethought
>  Russ> (namely, snipping unneeded quoted material) into software.
>  Russ> Efforts of that sort are invariably doomed to failure.

It is a attempt to have software FACILITATE using the correct etiquette.  
It means that software should provide a method which allows the human to 
do the right thing quickly and easily.

>Maybe they're talking about digests?  I found the feature of TM to be
>able to hit "a" (or was it "f") on the header line of a submessage
>quite useful.  It was a MIME multipart message with a message/rfc822
>part, I think, where I found that useful.
>
>As the evaluation form doesn't really say, and I like to see the good
>things in people... :-)
>
>I would like to see the signature omitting stuff, though.

It's not talking specifically about digests - but this would be a VERY 
good feature and is right in line with the spirit of the GNKSA and this 
suggestion (it's not a requirement to get the seal).

More typically it means allowing the user to select a portion of the 
message and then have the agent reply with only that part of the message 
being included as quoted text.  I'd demonstrate on this message but I 
think everything here needs to be left in.  It is frequently used in 
conjunction with omitting the sig - i.e. to reply to the whole message 
including the sig just select the whole message and then reply.

-- 
John Moreno

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[Russ Allbery]

(Still cc'ing people who may or may not be on the mailing list.)

John Moreno <phenix@interpath.com> writes:

> 7c is a requirement that makes it compatible with son-of-1036,

This provision of son-of-1036 has been roundly rejected and dismissed as
horribly broken by the IETF working group forming the RFC 1036
replacement.  It is in no way an applicable news standard.  The current
inclination of that working group, by my reading of the conversation, is
to either require (as a MUST) that all news software handle References of
arbitrary size or set a cutoff in the 10KB+ range.

Furthermore, should Gnus comply with 7c, it would be in *violation* of
what's likely to become the new news standard, given that it will almost
certainly be recommended that References *never* be truncated if it can be
avoided.

> and is in there to acknowledge a problem with some SERVERS - i.e. ones
> that don't handle long lines.

Do you have some evidence of this being a problem in practice, rather than
theory?  INN certainly has no such problem that I'm aware of, at least in
a relatively recent version.  tin used to have a problem with large
overview files (larger than this extremely small limit -- about 4K as I
recall), but that bug has long since been fixed.

> Son-of-1036 specifies that it not be longer than 1000 octets including
> EOL (2 octets to allow for dos cr/lf),

Son-of-1036 is severely broken in this regard and should be ignored.

> Also note that this should allow any one message to have references
> going back between 30-40 messages.

Assuming airnews or Pine message IDs, about 15-20 is more accurate.  But
threading becomes easier the fuller the References header is.

> This seems, well, not to harsh to me - and can easily result in messages
> where the references header is much larger than the message itself.

Yes, it can.  But this is a meaningless optimization.  One should never
optimize without profiling; if this were actually a source of concern for
news bandwidth, then sure, I can see making provisions concerning it.
Even a brief inspection of article size will show that it's not, however.

> I'm sorry to hear that - if you have fixed 16c then the only thing
> that's out of place is 7c and this can result in either the users server
> not accepting the article or other servers not propagating their
> messages.

I find this highly unlikely, but I'm willing to be convinced that I'm
wrong if you have some evidence to support this statement.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[Russ Allbery]

Kai Grossjohann <grossjohann@charly.cs.uni-dortmund.de> writes:

> Maybe they're talking about digests?  I found the feature of TM to be
> able to hit "a" (or was it "f") on the header line of a submessage quite
> useful.  It was a MIME multipart message with a message/rfc822 part, I
> think, where I found that useful.

Hmm.  Okay.  I can buy this, although I encounter very, very few digests.
They're common in some varieties of mailing list, but pretty uncommon on
Usenet overall (although admittedly I have seen them).  Most of what I see
on Usenet in digest format are FAQs.

> As the evaluation form doesn't really say, and I like to see the good
> things in people... :-)

Right.  :)

> I would like to see the signature omitting stuff, though.

So would I, although I don't really need it.  Following is a bit of elisp
code I wrote that has been referred to by at least one friend of mine as
"the best reason to switch to using emacs to post and send mail that I've
seen."  :)

;; Delete anything between the current point and the signature (defined as
;; the block starting with "-- " at the beginning of a line.  *Extremely*
;; useful for killing quoted text.
(define-key message-mode-map "\C-cz" 'rra-kill-to-signature)
(defun rra-kill-to-signature ()
  "Deletes all text up to the signature."
  (interactive)
  (save-excursion
    (push-mark (point) t t)
    (re-search-forward "^-- ")
    (forward-line -1)
    (kill-region (mark) (point))))

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[John Moreno]

[Added Russ Allbery to recipients]

Lars Magne Ingebrigtsen wrote:

>Here's the latest GNKSA evaluation report.  16c has been fixed, I
>think, but 7c will not be fixed.

7c is a requirement that makes it compatible with son-of-1036, and is in there to acknowledge a problem with some SERVERS - i.e. ones that don't handle long lines.  Son-of-1036 specifies that it not be longer than 1000 octets including EOL (2 octets to allow for dos cr/lf), and that (from left to right) the first reference and the last three never be deleted.  Note that 1036 ALLOWS this but doesn't set any guidelines for when and how to do so.  Also note that this should allow any one message to have references going back between 30-40 messages.  This seems, well, not to harsh to me - and can easily result in messages where the references header is much larger than the message itself.

>The GNKSA has evolved from a sensible bare-bones minimum thang into
>something, uh, else, and I think the whole think has become
>pointless.  Gnus will therefore from now on not strive for GNKSA
>compliance.  

I'm sorry to hear that - if you have fixed 16c then the only thing that's out of place is 7c and this can result in either the users server not accepting the article or other servers not propagating their messages.

>-- 
>(domestic pets only, the antidote for overdose, milk.)
>  larsi@ifi.uio.no * Lars Magne Ingebrigtsen
>------- Start of forwarded message -------
>Karl-Johan Noren wrote:
>
>[...]
>
>>> Also did you send a copy of the review to the author?
>>
>>Nope - but I guess I should have, and I don't have the review
>>available on the computer I use right now (I'm not sure it's
>>still on my Unix account either). Gnus have a homepage at
>>
>>   http://www.gnus.org/
>>
>>though, I think.
>
>Well here it is:
>
>============================================================================
>
>                                          GNKSA   Evaluation  Form  v2.0
>
>
>Product Name           : Gnus
>Product Version        : 5.3
>Tested on platform     : Unix/GNU Emacs 19.34
>Available for platforms: Emacs 19
>Evaluation date        : December 10, 1997
>Evaluated by           : Karl-Johan Norén
>
>
>Summary
>=======
>
>Regarding the strict GNKSA requirements (MUSTs), this software:
>
>[ ] PASSES, hence can from now on proudly carry the Seal.
>[X] FAILS on the following points:
>    7c   Does not restrict references sensibly
>    16c  Does not warn when posting quoted text only
>
>
>Additionally, the software violates the `soft' GNKSA requirements
>(SHOULDs) in the following way:
>    10d  Does not omit (proper) signatures from quoted text
>    10e  Does not let the user indicate which part to followup to
>    10g  Attribution line lacks Message-ID of original article
>    16b  Does not refuse posting an empty article
>    16d  Does not refuse to post quoted text only
>    16f  Does not try to prevent posting multiple copies entirely
>
>
>The software sports the following nice net-keeping features unmentioned
>by the GNKSA:
>
>Fully customisable via elisp.

10d  - speaks for itself.
10e  - this applies more to GUI newsreaders and allows them to select the
       portion of the article which they intend to respond to.  It also
       allows the user to include the sig if wanted. 
10g  - well, I disagree with this one myself.  But it's not a requirement,
       and several newsreaders can use it to get that article.
16b  - I guess this could be necessary with some control messages.
16d  - I'm not sure why somebody would need to post a message that was only 
       quoted.
16f  - Does gnus really do this?  Post the same article multiple times?

-- 
John Moreno

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[Kai Grossjohann]

>>>>> On 04 Jan 1998, Russ Allbery said:

  GNKSA>     10e  Does not let the user indicate which part to followup to

  Russ> This is nonsensical.  In the entire time that I've been
  Russ> reading and posting to Usenet, I've never had a need for any
  Russ> such thing, or even have any coherent idea how one would *do*
  Russ> such a thing.  It sounds to me like a broken attempt to encode
  Russ> etiqutte that requires human intervention and forethought
  Russ> (namely, snipping unneeded quoted material) into software.
  Russ> Efforts of that sort are invariably doomed to failure.

Maybe they're talking about digests?  I found the feature of TM to be
able to hit "a" (or was it "f") on the header line of a submessage
quite useful.  It was a MIME multipart message with a message/rfc822
part, I think, where I found that useful.

As the evaluation form doesn't really say, and I like to see the good
things in people... :-)

I would like to see the signature omitting stuff, though.

-- 
Kai Grossjohann, Informatik VI        grossjohann@ls6.cs.uni-dortmund.de
Uni Dortmund, D-44221 Dortmund        http://ls6-www.cs.uni-dortmund.de/
                                      Vox +49 231 755 5670, Fax -2405
I like both kinds of music.

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
>> The GNKSA has evolved from a sensible bare-bones minimum thang into
>> something, uh, else, and I think the whole think has become pointless.

Russ Allbery <rra@stanford.edu> writes:
> The GNKSA started as a very reasonable and interesting endeavor; it's
> really a shame that it's turned into something this useless and misguided.

The real horror is that GNKSA started out as nothing more challenging
than codifying the behavior of rn (for the most part), and yet I
recall such innumerable complaints about all the supposedly heavy
requirements being forced on all those suffering software authors,
most of whom just somehow couldn't get it right.

[John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[Lars Magne Ingebrigtsen]

Here's the latest GNKSA evaluation report.  16c has been fixed, I
think, but 7c will not be fixed.

The GNKSA has evolved from a sensible bare-bones minimum thang into
something, uh, else, and I think the whole think has become
pointless.  Gnus will therefore from now on not strive for GNKSA
compliance.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen
------- Start of forwarded message -------
Message-Id: <199712280107.UAA02498@mail.interpath.net>
Subject: Re: GNKSA and Gnus
Date: Sat, 27 Dec 97 20:07:56 -0500
From: John Moreno <phenix@interpath.com>
To: "Karl-Johan Noren" <k-j-nore@dsv.su.se>,
        "Lars Magne Ingebrigtsen" <larsi@gnus.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Karl-Johan Noren wrote:

[...]

>> Also did you send a copy of the review to the author?
>
>Nope - but I guess I should have, and I don't have the review
>available on the computer I use right now (I'm not sure it's
>still on my Unix account either). Gnus have a homepage at
>
>   http://www.gnus.org/
>
>though, I think.

Well here it is:

============================================================================

                                          GNKSA   Evaluation  Form  v2.0


Product Name           : Gnus
Product Version        : 5.3
Tested on platform     : Unix/GNU Emacs 19.34
Available for platforms: Emacs 19
Evaluation date        : December 10, 1997
Evaluated by           : Karl-Johan Norén


Summary
=======

Regarding the strict GNKSA requirements (MUSTs), this software:

[ ] PASSES, hence can from now on proudly carry the Seal.
[X] FAILS on the following points:
    7c   Does not restrict references sensibly
    16c  Does not warn when posting quoted text only


Additionally, the software violates the `soft' GNKSA requirements
(SHOULDs) in the following way:
    10d  Does not omit (proper) signatures from quoted text
    10e  Does not let the user indicate which part to followup to
    10g  Attribution line lacks Message-ID of original article
    16b  Does not refuse posting an empty article
    16d  Does not refuse to post quoted text only
    16f  Does not try to prevent posting multiple copies entirely


The software sports the following nice net-keeping features unmentioned
by the GNKSA:

Fully customisable via elisp.

Support for NoCeM (I haven't tested this, though).

Asks if posts are to be sent to unknown groups (ie groups not
present on the newsserver).

Good easily customisable threading, and it's easy to fetch
older articles in the thread.

Allows colouring of quoted text, signatures, new text, headers etc.


Additional Comments:

I haven't been able to test the 998-character limit on references
lines, it does however wrap the reference line.


Checklist
=========                                                       (M)UST /
                                                                (S)HOULD
1) Displays all essential header information
   Software clearly displays:
   [Y] a) Article's author (From)                                      M
   [Y] b) Article's Subject                                            M
   [Y] c) List of groups posted to (Newsgroups)                        M
   [Y] d) Where (and how) to direct followups (Followup-To)            M
   [Y] e) Where to reply to if not the From-address (Reply-To)         M
[Y] PASS: Satisfies all MUSTs                                          M

2) Provides clear, separate commands for new  posting, followup, and
   e-mail reply
   [Y] a) for posting a new article                                    M
   [Y] b) for posting a followup article                               M
   [Y] c) for replying by e-mail                                       M
   [Y] d) Uses standard terminology                                    S
   [Y] e) Avoids ambiguous terminology                                 S
[Y] PASS: Satisfies all MUSTs                                          M

3) Provides cross-posting functionality
   [Y] a) Allows specifying multiple groups                            M
   [Y] b) Warns about, or prevents, posting to large numbers of groups S
   [Y] c) Strongly encourages setting Followup-To: on large crossposts S
          (`Y' if large crosspostings are disallowed)
[Y] PASS: Satisfies all MUSTs                                          M

4) Allows users to change essential headers
   [Y] a) Allows editing Subject at all times during composition       M
   [Y] b) Allows specifying new Subject of at least 70 characters      M
   [Y] c) Allows setting "Followup-To: poster"                         M
[Y] PASS: Satisfies all MUSTs                                          M

5) Ensures followups and e-mail replies contain a correct Subject
   [Y] a) Prepends "Re: " if (and only if) not already present         M
   [Y] b) Preserves entire original Subject (modulo minor repairs)     M
[Y] PASS: Satisfies all MUSTs                                          M

6) Directs followups to the correct newsgroups
   [Y] a) Posts to groups in Followup-To if present                    M
   [Y] b) Initiates e-mail reply rather than a followup posting on
          "Followup-To: poster", clearly informing the user            M
[Y] PASS: Satisfies all MUSTs                                          M

7) Make sure followups contain valid References
   [Y] a) Creates References header with Message-ID of original article
          as the last element                                          M
   [Y] b) Includes last three References from original                 M
   [N] c) Ensures References will fit in 998 characters                M
   [Y] d) Keep as many References from original as fit                 S
   [Y] e) Does not propagate broken Message-IDs in original References S
[N] PASS: Satisfies all MUSTs                                          M

8) Direct e-mail replies to the correct address
   [Y] a) Uses Reply-To if present                                     M
   [Y] b) Uses From address otherwise                                   
[Y] PASS: Satisfies all MUSTs                                          M

9) Allow the user to change her mind about whether to post or mail (or
   do both) and behave if doing both
   [Y] a) Allows users to change their mind and mail rather than
          post after having initiated a followup message               M
   [Y] b) Allows users to change their mind and post rather than
          mail after having initiated a reply message                  M
   [Y] c) Does not offer both posting and mailing as default behaviour M
   [Y] d) Inserts a notification that the message was posted as well
          as mailed in the e-mail copy when both posting and mailing
          a followup article                                           S
[Y] PASS: Satisfies all MUSTs                                          M

10) Provide adequate quotation and attribution facilities
    [Y] a) Allows including quoted original                            M
    [Y] b) Clearly distinguishes quoted material                       M
    [Y] c) Prefixes quoted material with `>'/`> '                      S
    [N] d) Omits correctly delimited signatures from quoted material   S
    [N] e) Provides a means of indicating which part(s) to followup to S
    [Y] f) Attribution line containing original author precedes quotes M
    [N] g) Attribution contains Message-ID of quoted article           S
[Y] PASS: Satisfies all MUSTs                                          M

11) Provide a user-specified "Subject: " header
    [Y] a) Requires non-empty, user-specified Subject for new articles M
    [Y] b) Refuses posting articles without, or with an empty, Subject M
    [Y] c) Does not provide default Subject if user did not set one    M
    [Y] d) Allows changing the Subject at any time while editing       M
[Y] PASS: Satisfies all MUSTs                                          M

12) Provide a valid "From: " header
    [Y] a) Sets "From: " header to syntactically valid e-mail address  M
    [Y] b) Refuses posting articles without a syntactically valid
           "From: " header                                             M
    [Y] c) Uses correct e-mail addresses (valid and belonging to the
           user) only, as far as it can possibly know                  S
[Y] PASS: Satisfies all MUSTs                                          M

13) Allow users to both cancel and supersede their own articles (and
    _no_ others!)
    [Y] a) Allows cancelling articles                                  S
    [Y] b) Allows superseding articles                                 S
    [Y] c) As far as possible, does not allow cancelling or superseding
           other peoples' articles                                     M
    [Y] d) Uses standard terminology                                   S
[Y] PASS: Satisfies all MUSTs                                          M

14) Try to respect the 80-character line-length convention
    [Y] a) Articles are posted as edited, with linebreaking intact     S
    [Y] b) Warns about lines over 80 characters                        S
    [Y] c) Does not refuse to post articles containing long lines      S
    [Y] d) Allows rewrapping quoted text                               S
    [Y] e) Enforces formatting requirements on article after external
           editing (`Y' if there is no support for external editors)   S
[Y] PASS: Satisfies all MUSTs                                          M

15) Separate signatures correctly, and don't use excessive ones
    [Y] a) Uses (and enforces) standard signature delimiter            S
    [Y] b) Warns against or refuses to use excessive signatures        S
[Y] PASS: Satisfies all MUSTs                                          M

16) Try to prevent obvious user errors
    [Y] a) Warns when attempting to post empty articles                M
    [N] b) Refuses posting empty articles                              S
    [N] c) Warns when post articles containing quoted material only    M
    [N] d) Refuses posting quoted-text-only articles                   S
    [Y] e) Warns against posting multiple copies (if possible at all)  M
    [N] f) Prevents multiple posting entirely                          S
[N] PASS: Satisfies all MUSTs                                          M

17) Post human-readable articles unless ordered otherwise
    [Y] Does not (and can not) encode or encrypt articles unless
        on explicit user demand                                        M
[Y] PASS: Satisfies all MUSTs                                          M

18) Provide self-protection
    [Y] Allows filtering out annoying articles (killing)               S
[Y] PASS: Satisfies all MUSTs                                          M

19) Be kind to servers, leave room for others
    [Y] a) Does not unnecessarily open multiple connections            M
    [Y] b) Does not generate excessive server load otherwise           M
[Y] PASS: Satisfies all MUSTs                                          M





------- End of forwarded message -------

Re: [John Moreno <phenix@interpath.com>] Re: GNKSA and Gnus

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Here's the latest GNKSA evaluation report.  16c has been fixed, I
> think, but 7c will not be fixed.

[snip]

| [X] FAILS on the following points:
|     7c   Does not restrict references sensibly
|     16c  Does not warn when posting quoted text only

[snip]

| 7) Make sure followups contain valid References
|    [Y] a) Creates References header with Message-ID of original article
|           as the last element                                          M
|    [Y] b) Includes last three References from original                 M
|    [N] c) Ensures References will fit in 998 characters                M

7c is complete and utter hogwash.  News readers have absolutely no
business arbitrarily truncating References headers and destroying
threading information, and nothing in any news standard requires this.

And on top of that, there are absurdities like:

|     10e  Does not let the user indicate which part to followup to

This is nonsensical.  In the entire time that I've been reading and
posting to Usenet, I've never had a need for any such thing, or even have
any coherent idea how one would *do* such a thing.  It sounds to me like a
broken attempt to encode etiqutte that requires human intervention and
forethought (namely, snipping unneeded quoted material) into software.
Efforts of that sort are invariably doomed to failure.

|     10g  Attribution line lacks Message-ID of original article

And this is absurd and utterly wasted space.  Inclusion of message IDs in
attribution lines serves absolutely no purpose other than to drop hash not
intended for human consumption at the beginning of human-readable text.
This is the purpose served by the References header, not the attribution
line.

> The GNKSA has evolved from a sensible bare-bones minimum thang into
> something, uh, else, and I think the whole think has become pointless.
> Gnus will therefore from now on not strive for GNKSA compliance.

Thank you.

The GNKSA started as a very reasonable and interesting endeavor; it's
really a shame that it's turned into something this useless and misguided.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>