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

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

[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

[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: GNKSA and Gnus

[Matt Simmons]

I can't be the only one who finds it weird to be reading a debate
about the proper way to form References headers in which the GNKSA is
complaining about Gnus' method using an MUA that apparently disregards 
References headers entirely.

Hmm.

Matt

-- 
     Matt Simmons  -  simmonmt@acm.org  -  http://www.netcom.com/~simmonmt
    Originality is the fine art of remembering what you hear but forgetting
	    where you heard it.  --Laurence Peter.  Canadian writer

Re: GNKSA and Gnus

[Robert Bihlmeyer]

Hi,

>>>>> On 04 Jan 1998 15:58:05 -0800
>>>>> Matt Simmons <simmonmt@acm.org> said:

 Matt> I can't be the only one who finds it weird to be reading a
 Matt> debate about the proper way to form References headers in which
 Matt> the GNKSA is complaining about Gnus' method using an MUA that
 Matt> apparently disregards References headers entirely.

You're not. But we gnusheads sometime forget, that some people still
use mail readers (feh) to read mail. Apperently, Claris emailer can't
dig references.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

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: GNKSA and Gnus

[Russ Allbery]

John Moreno <phenix@interpath.com> writes:

> 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.

I've been thinking this over, and I believe the reason why I was objecting
to this before was largely due to a misconception of the point of Soft
features.  It's one that would seem to be cleared up by adding another
level; there are many Soft features that I would consider to be
appropriate in all circumstances, and then there are many that I think
should be decidedly optional and which some newsreaders would have no
interest whatsoever in implementing (for legitimate reasons).

Making that division more apparent may be helpful.

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

Re: GNKSA and Gnus

[Per Abrahamsen]

[ Lars:  I'd be willing to work on 10d and 10e if you are interested. ]

The GNKSA requirements seem reasonable to me.  Some of the SHOULD
doesn't really apply to Gnus because of special concerns, which I
suspect is why they are SHOULD and not MUST.

>     7c   Does not restrict references sensibly

I often have to manually edit the references line when posting
followups in gnu.misc.discuss in order to make INN accept it.  I guess
it happens in gnu.misc.discuss because

1) The threads there are very deep.
2) There are a high fraction of Gnus users, thus none of the posters
   software will restrict the header.

This is with 

nntp-server-type's value is 
"200 ssv2.dina.kvl.dk InterNetNews NNRP server INN 1.5.1 17-Dec-1996 ready (posting ok).\n"

I found this in the config file.

##  Maximum size of a single header.
#### =()<MAXHEADERSIZE          @<MAXHEADERSIZE>@>()=
MAXHEADERSIZE           1024

I would feel more safe having Gnus truncate the header, than doing it myself.

> Additionally, the software violates the `soft' GNKSA requirements
> (SHOULDs) in the following way:
>     10d  Does not omit (proper) signatures from quoted text

I think Gnus should do that.  The default Gnus citation handler is too
barebone, probably in reaction too the alternative citation handler
(SuperCite) which is too advanced.

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

This is something Gravity does, and in general a good idea.  It migth
make less sense for Gnus.  However, I think it would be nice if
quoting would be restricted to the currently region in the messsage
being quoted, iff `transient-message-mode' is on, and the region is
active.

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

This is the only point I disagree with.  The message-id is in the
references line, which should be enough.  I don't think therte is
anything resembling a consensus on whether it should be included in
the attribution line as well.

>     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

Actually, I believe I have gotten warnings for all three of these.

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

Command to fetch FAQ for the group.

Re: GNKSA and Gnus

[Russ Allbery]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I often have to manually edit the references line when posting followups
> in gnu.misc.discuss in order to make INN accept it.  I guess it happens
> in gnu.misc.discuss because

> 1) The threads there are very deep.
> 2) There are a high fraction of Gnus users, thus none of the posters
>    software will restrict the header.

I stand corrected.

> ##  Maximum size of a single header.
> #### =()<MAXHEADERSIZE          @<MAXHEADERSIZE>@>()=
> MAXHEADERSIZE           1024

I believe this only affects headers which are not continued.  If one uses
continuation lines, headers can be much larger.  (Or that at least is my
understanding.)  Keep in mind that the version of Gnus that I'm using
still wraps References using continuation lines; I think Lars took that
out at some point?

It sounds like either the header wrapping code needs to be put back in or
Gnus needs to shorten the Reference headers it generates, in the short
term.  In the long term, I expect the new news RFC to require References
headers not be truncated.

> This is something Gravity does, and in general a good idea.  It migth
> make less sense for Gnus.  However, I think it would be nice if quoting
> would be restricted to the currently region in the messsage being
> quoted, iff `transient-message-mode' is on, and the region is active.

I still don't think this idea makes any sense.  But YMMV.

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

Re: GNKSA and Gnus

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> [ Lars:  I'd be willing to work on 10d and 10e if you are interested. ]

Sure.

> nntp-server-type's value is 
> "200 ssv2.dina.kvl.dk InterNetNews NNRP server INN 1.5.1 17-Dec-1996 ready (posting ok).\n"
> 
> I found this in the config file.
> 
> ##  Maximum size of a single header.
> #### =()<MAXHEADERSIZE          @<MAXHEADERSIZE>@>()=
> MAXHEADERSIZE           1024

Hm.  Is this the default?  If so, I think Gnus should just go back to
folding the header.

> >     10d  Does not omit (proper) signatures from quoted text
> 
> I think Gnus should do that.  The default Gnus citation handler is too
> barebone, probably in reaction too the alternative citation handler
> (SuperCite) which is too advanced.

Providing an alternative to `message-cite-original' that removes the
signature might be nice.

> >     10e  Does not let the user indicate which part to followup to
> 
> This is something Gravity does, and in general a good idea.  It migth
> make less sense for Gnus.  However, I think it would be nice if
> quoting would be restricted to the currently region in the messsage
> being quoted, iff `transient-message-mode' is on, and the region is
> active.

Hm.  Perhaps, but I can't really see this being used much.

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

Re: GNKSA and Gnus

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Per Abrahamsen <abraham@dina.kvl.dk> writes:

>> I found this in the config file.

>> ##  Maximum size of a single header.
>> #### =()<MAXHEADERSIZE          @<MAXHEADERSIZE>@>()=
>> MAXHEADERSIZE           1024

> Hm.  Is this the default?  If so, I think Gnus should just go back to
> folding the header.

Yup, that's the default.  And yes, that would be my preference as well.

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

Re: GNKSA and Gnus

[Lars Magne Ingebrigtsen]

Russ Allbery <rra@stanford.edu> writes:

> > Hm.  Is this the default?  If so, I think Gnus should just go back to
> > folding the header.
> 
> Yup, that's the default.  And yes, that would be my preference as well.

I've now switched back again to folding.

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

Re: GNKSA and Gnus

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hm.  Is this the default?  If so, I think Gnus should just go back to
> folding the header.

Please do.  Or, see my proposal in "References again" thread.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: GNKSA and Gnus

[John Moreno]

Russ Allbery wrote:

>Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
>> I often have to manually edit the references line when posting followups
>> in gnu.misc.discuss in order to make INN accept it.  I guess it happens
>> in gnu.misc.discuss because
>
>> 1) The threads there are very deep.
>> 2) There are a high fraction of Gnus users, thus none of the posters
>>    software will restrict the header.
>
>I stand corrected.
>
>> ##  Maximum size of a single header.
>> #### =()<MAXHEADERSIZE          @<MAXHEADERSIZE>@>()=
>> MAXHEADERSIZE           1024
>
>I believe this only affects headers which are not continued.  If one uses
>continuation lines, headers can be much larger.  (Or that at least is my
>understanding.)  Keep in mind that the version of Gnus that I'm using
>still wraps References using continuation lines; I think Lars took that
>out at some point?
>
>It sounds like either the header wrapping code needs to be put back in or
>Gnus needs to shorten the Reference headers it generates, in the short
>term.  In the long term, I expect the new news RFC to require References
>headers not be truncated.

It's going to have to either require or allow it to be truncated at some 
point - otherwise you'll have references lines that grow infinitely long. 
 I know of several threads that are more than a year old - I hate to 
think how long they would be if software didn't truncate the header.

Approximately 1k REALLY is the current expected behavior.  And if 
newsreaders don't do it, servers and users will.  It is also a attempt to 
make the standard larger than what might otherwise be settled upon - 
after all assuming that all of the articles are there threading can take 
place with just one, and if articles are missing keeping only 5 or 6 back 
references is enough for normal situations.  And I can't count the number 
of users (most using TIN) who I've chided for deleting it entirely - I 
end up telling them that since they feel they must cut it, to at least 
leave in the last reference.  Unfortunately I often get the reply that it 
is simply easier to cut it all out than to try to edit it.

-- 
John Moreno

Re: GNKSA and Gnus

[Lars Balker Rasmussen]

John Moreno <phenix@interpath.com> writes:
> It's going to have to either require or allow it to be truncated at some 
> point - otherwise you'll have references lines that grow infinitely long. 
>  I know of several threads that are more than a year old - I hate to 
> think how long they would be if software didn't truncate the header.

Good argument.  However, it also shoots down the definition in
son-of-1036, where some IDs are sacred.  In a year-long thread it's easy
to imagine the first, the latest and all IDs with _-_ in them to be more
than 1000 chars long.  Then what ID should be cut?
-- 
Lars Balker Rasmussen, Software Engineer, Mjolner Informatics ApS
lbr@mjolner.dk