Re: [Pan-users] RFC versus sever versus client

[Per Hedeland]

On 2016-11-11 15:38, DLSauers wrote:
> On Fri, 11 Nov 2016 10:08:31 +0100, Per Hedeland wrote:
> 
>> Understood. A 5xx reply code indicates a fatal error, and the client
>> giving up on the server and disconnecting is the "normal"/default
>> behavior 
> 
> Pan and KNode do this...
> 
> The monkey in the works is: thunderturkey
> 
> Connect
> 200 Sever blah blah
> MODE READER
> 500 
> LIST
> 
> It just ignores the 500 and continues on so it works to get the initial 
> group list, thus you can do all the other things, read, post etc..

Yes, you already said so:-) - and I didn't say that it is wrong to do so
either, on the contrary:

>> Absent such specifications, it is
>> ultimately up to the implementor (and users) of the client do decide
>> which client behavior that is most *useful* when a specific command
>> returns a specific 5xx code.

And in the specific case of the MODE READER command, with the specific
reply code 500 - which means "Command not understood" - it is useful,
and can even be considered reasonable, to ignore the reply. The client
doesn't *need* any result from the command (unlike e.g. LIST) in order
to proceed - it is just issuing it because some *servers* need it to be
issued in order to allow reader commands such as LIST. (In INN, a
special "reader service" program 'nnrpd' is forked at that point - the
reader commands are not implemented in the "main" 'innd' program which
is dedicated to "feeder service".)

I.e. if the server says "Command not understood" in response to MODE
READER, it obviously does *not* need that command, and it's perfectly OK
for the client to go on with its reader business.

> A HUGE HAMMER TO HIT THEM ON THE HEAD! They are very pedantic if it aint 
> in the RFC we don't have to do it that way, and since server x doesn't 
> support RFC xxxx F off!

Seems like a very self-contradicting principle.:-)

> What I after is 
> 
> RFC xxxx says do this! Period.

As I already showed, RFC 3977 does indeed say that a server should
support MODE READER - but I can't see how that is useful to you, when
they don't claim to support 3977 anyway.

> Again, what I am after is the supporting "law" of the land as it were... 
> 
> Bluntly, I am not really caring what RFC xxx or RFC yyy says... 

It seems you are also rather self-contradicting.:-)

> This is listed in 3977, but if predates 3977, then what RFC is it in?? 

Please re-read my original message. It is not in any RFC preceding 3977,
because there was no RFC for it to be in. (Well actually it is in RFC
2980 too, but that's not a specification or a standard, just a
collection of useful info.) RFC 977 was published in 1986, by the same
people who also did the very first implementation (this was back in the
days where "RFC" actually meant what the acronym expands to).

For the following 20 years, where perhaps the first 10 saw the most
dramatic evolution in the use of NNTP transport for Usenet News, there
was nothing. But of course this didn't mean that developers who needed
new functionality in the protocol just gave up on it - they discussed
with others in their community, and implemented what they needed. And
when INN was the only game in town if you wanted a performant server,
and it required the MODE READER command for reader service, of course
"all" the client developers implemented it.

As I wrote, it's great that 3977 now exists, but it is pretty much too
late. AFAIK current INN implements it, but I wouldn't be surprised if
it's the only server that does, and I can't see support being added to
existing clients - there's simply no need for it.

> server x supports most of the basic NNTP protocol as specified in RFC-977.
> The commands IHAVE, NEWGROUPS and NEWNEWS are not implemented, but at 
> least
> give valid response codes if a newsreader tries to use them. server x also
> supports the XOVER and AUTHINFO commands as specified in RFC-2980. XOVER
> never sends information about the line counts and byte counts of messages.

This is a perfectly reasonable approach I think, and with such a
statement, arguing that there is some "law" that says that they must do
this or that seems completely pointless. What I don't understand is why
they would be so violently opposed to a trivial MODE READER
implementation, with the simple argument that some readers expect it.
Perhaps you are just using the wrong approach?:-)

> Doing what I've done for now with my solution 200 will work to appease 
> Pan, Knode..
> 
> 201 would require the server to check that AUTHINFO has been done, a 
> valid login has been done, to present the 201 response..as only if you 
> logged in can you post, it also depends on the group the user is in.

No, it is not the intent that the 200 vs 201 reply should care about
such things, it is rather a property of the server whether posting is
allowed or not. It should be the same code that is given when the client
initially connects.

> You and/or others seem to better grasp these RFC's.. I read them and they 
> seem to contradict themselves....

I think it may just be that you expect to find things that typically
aren't there...

> It appears that KNode at one time in the 0.7x range worked as its listed 
> as a compatible client.. obviously later versions tightened up the code 
> to follow RFC, and thus no longer work...Pan from .133 to .139 don't.

I have never looked at the KNode code, and I'm not sure if you are
suggesting that earlier versions of Pan worked - but I'm pretty sure
that no developer has made an intentional decision to change from
accepting a 5xx response to MODE READER to not doing it - it just
doesn't make sense, and has the potential for causing completely
unnecessary problems.

But a code reorganization could very well have caused it, and looking at
the current Pan code, I can *imagine* that even Pan accepted 5xx before
the multi-server support was implemented. If your reader only talks to a
single server, an implementation that just goes send-a-command -
wait-for-response - analyse-response is nice and straightforward to
write - and in such an implementation it is also more straightforward to
ignore a "bad" reply to a specific command.

With a good implementation of multi-server support on the other hand,
you don't want to write the code like that - you want to be able to
issue commands to the different servers in parallel, and proceed at a
rate appropriate for each server, not always having to wait for the
slowest one to reply. So you decouple the sending of commands and the
reading of responses, and process the responses (when they arrive) in a
way that is independent of the command given.

In any case, that's what Pan's current code looks like - and as far as I
can see, if it gets a 5xx response, it's end of story (for that server
at least), regardless of what the command was. It *could* be changed...

> Part of what I am going to do is implement CAPABILITIES in at least the 
> basic form..

This would be completely pointless - what do you hope to achieve by
that?

> I just want to nail down that per the NNTP protocol the server really 
> should have implemented MODE READER, the fact that other clients are more 
> lax in requiring it does not mean its not REQUIRED. Correct?

If a server claims to implement RFC 3977, my reading is that MODE READER
support is required. If a server doesn't claim to implement any RFC,
nothing is required. In that case, a reasonable approach is to make as
many clients as possible happy, as long as it doesn't take an
unreasonable amount of effort.

--Per