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

[Per Hedeland]

On 2016-11-11 05:17, DLSauers wrote:
> On Thu, 10 Nov 2016 23:12:16 +0100, Per Hedeland wrote:
> 

[snip]

>> And regarding Duncan's mention
>> of what is known as "Postel's principle", a resonable application of
>> that is that if you are an NNTP server that only provides reader
>> service, and a client asks you for reader service, you just say "sure,
>> go ahead" - while a client ignoring an error response from the server
>> may not be, since it can lead to all kinds of difficult-to-debug
>> problems down the line.
> 
> That sounds logical but the way that server is written.. It doesn't work 
> that way.

Obviously not:-) - if it did, this discussion wouldn't be needed.

> Connection
> 200 sever intro blah blah blah
> MODE READER
> 500 Unknown Command
> 
> At this point */PAN/* goes offline, its  done. Refuses to do anything 
> with any other server. You can't get a list of groups from this server.

Understood. A 5xx reply code indicates a fatal error, and the client
giving up on the server and disconnecting is the "normal"/default
behavior (if it affects Pan's behavior towards *other* servers, that's
another thing - may or may not be a bug, but perhaps we can leave it out
of this discussion). In principle a standard could specify some kind of
"trial and error" protocol, and say that "If command X generates a 500
reply, try command Y instead" or even "Always ignore the reply to
command X", but I've never seen that. 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. But giving up and disconnecting can not be
considered *wrong*.

>> Anyway, enough rambling - I think the answer, maybe not to your actual
>> question but to the question of what needs to be fixed, is perfectly
>> clear from RFC 3977 - and it is what you could expect from a standard
>> created by people that actually *have* the historical perspective. It
>> says:
>>
>> In section 5.2.2, about the CAPABILITIES command:
>>
>>    This command MAY be issued at any time; the server MUST NOT require
>>    it to be issued in order to make use of any capability.
> 
> To me that sounds, well illogical, and that you are ASSUming stuff...

This is what the standards-track RFC says - it is as close to the law
that you get on the Internet, and how it sounds to you or anyone else
doesn't matter. If your implementation doesn't do what it says, it is
not standards-compliant. The *reason* for this wording is in the
background I described earlier - the people behind RFC 3977 are smart
and well aware of that background, and realise that they can not, after
20 years without evolving standards support for implementors, publish an
RFC that, if implemented by a server, would make every existing client
implementation unable to use that server. Thus a compliant server MUST
implement the CAPABILITIES command that they invented, but it MUST NOT
require that a client makes use of it.

>> In section 5.3.2, about the MODE READER command:
>>
>>    If the server is not mode-switching, then the following apply:
>>
>>    o  If it advertises the READER capability, it MUST return a 200 or
>>       201 response with the same meaning as for the initial greeting; in
>>       this case, the command MUST NOT affect the server state in any
>>       way.
> 
> This server does not implement CAPABILITIES so it can't advertise its 
> capabilities.

Hm, I actually thought that you said that earlier, but assumed that I
must have misunderstood. RFC 3977 says in 5.2.1 about CAPABILITIES:

   This command is mandatory.

(And in 3.4: "... some of the commands in this specification are
mandatory (they must be supported by all servers) ...".)

I.e. if the server in question does not implement CAPABILITIES, it is
not compliant with the current NNTP standard (probably most of the
world's NNTP servers aren't) - so why all the fretting about what the
RFCs say? If they don't care about compliance with the current standard,
the only reasonable alternative is to implement "best current practice"
- that does require some research, but it shouldn't take much to figure
out that "proper implementation of the MODE READER command, without
requiring that some other command has preceded it" is part of it.

>> If the implementation of the server in question is done per the letter
>> of 3977, it surely advertises the READER capability, 
> 
> The server in question does NOT respond to:
> 
> Does not implement 3977
> 
> CAPABILITIES
> MODE READER

As already noted, MODE READER predates 3977 by a decade and a half.

> And is not a mode switching ie, since it lacks support for IHAVE, etc.. 
> and unless you disable it you have to AUTHINFO to login to post..which in 
> doing so would allow spam, but also break Fido Policy 4 rules, which 
> require authenticated posting.
> 
> The transport of articles obviously occurs via FTN ie: binkd mostly 
> today, so thats why it doesn't do IHAVE.

Understood, but irrelevant, whether it is standards-compliant (3977 says
that it MUST implement MODE READER even if it is a reader-only server)
or not (the client has no way of knowing that it is a reader-only
server).

> That is what I did, I added a response  200 to this... as it appeases Pan 
> and Knode to work with this software...

Yes, per above this is what an NNTP server that provides reader service
*should* do. (Though note well that the reply can alternatively be 201,
and that there is an important difference.)

> If the CAPABILITIES command is not around for a client to parse what the 
> server supports, what is it for??? 

Of course it is for that, and the idea is very good, and commonly
included from day one when new protocols are specified. But it didn't
exist in NNTP before RFC 3977 was published, and the server clearly
doesn't implement it, so it's pretty moot in this discussion I think.

--Per