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

[Per Hedeland]

Hi,

Sorry for top-posting, but I'm afraid my normal interleaved-style reply
wouldn't be really useful here...

As a bit of background, NNTP hasn't had much interest from the Internet
standards groups for most of its existence, and thus implementations
have made the extensions they needed when they needed them. It is great
that RFC 3977 exists, but the MODE READER command, introduced by the INN
implementation in 1991 (part of what it needed to achieve its huge
performance improvement over the earlier "reference implementation"),
predates the CAPABILITIES command introduced in 3977 by some 15 years.

And the publication of an RFC obviously doesn't cause support for it to
magically appear in existing implementations, far less in existing
installations of those implementations. Thus there likely exists a large
number of NNTP servers that absolutely require that you use the MODE
READER command if you want reader service, yet will give you a 500 reply
if you try CAPABILITIES.

I think it is reasonable to expect implementors of NNTP servers to have
some knowledge of this background, and not think that RFC 3977 has
everything they need - e.g. RFC 2980 is a good read. It is perhaps
particularly ironic that implementors of a gateway to FidoNet of all
things lack the historical perspecive.:-) 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.

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.

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.

If the implementation of the server in question is done per the letter of
3977, it surely advertises the READER capability, and then per the above
it MUST return a 200 or 201 response to MODE READER, regardless of
whether the CAPABILITIES command has been issued by the client.

--Per Hedeland

On 2016-11-10 13:54, DLSauers wrote:
> On Thu, 10 Nov 2016 03:27:14 +0000, Duncan wrote:
> 
>> A practical and common RFC guideline and general policy is: Interpret
>> the RFCs strictly in what you send, but be more tolerant in what you are
>> prepared to receive.
> 
> If that is the case, then by that definition, Pan and Knode are the bug 
> sources in insisting on MODE READER before doing anything..while other 
> clients seem to just ignore, tolerate as you put it, and move on..
> 
>  
>> In this case, that would mean that regardless of whether the RFCs
>> mandate MODE READER or not, particularly given that there are known
>> servers out there that don't support it, pan should be prepared to work
> 
> What other servers don't support it???? I am curious for reference...
> 
> Which also would mean that Pan would not work them since MODE READER is 
> the first thing that comes in, and then BOOM, 500, offline.
> 
>> around receiving an error for the command, and continue without it the
>> best it can.
> 
> Well this is sort of what one other client does...it issues MODE READER, 
> gets 500 from this server, then just does LIST anyway...
>  
> Based on this:
> 
> https://tools.ietf.org/html/rfc3977#section-3.4.2
>  An implementation MAY, but SHOULD NOT, provide both transit and
>    reader facilities on the same server but require the client to select
>    which it wishes to use.  Such an arrangement is called a
>    "mode-switching" server.
> 
> it seems that Pan and Knode which issue this MODE READER get 500, should 
> then respond as another client does and just issue LIST
> 
> Since this is not a "transit" sever in that Server to server 
> communications will occur.. then MODE READER is not correct...????
> 
>> I /was/ going to suggest that a workaround would be using a firewall to
>> block the 500 error response and replace it with a synthetic response
> 
> My fix, responds to MODE READER, issues 200, Pan then does LIST, and 
> every one is happy... I've pulled messages from this server.. Not posted 
> with it yet, due to an issue not related to this....
> 
>  
>> Which means the only real solution if you're going to use pan with that
>> server is finding someone who knows enough C++ and is either familiar
>> enough with the RFCs or willing to /become/ familiar enough with them to
>> create and submit a patch...
> 
> I have a "hackish" fix to it for now... I working on more "proper" fix to 
> it after working out how this thing works... since its not my code 
> originally.... my original initial fix didn't work because of the way it 
> parses commands...
> 
> I have a fix... and working on adding some other things... 
> 
> Based on the RFC's a client *SHOULD*
> 
> Connect to SERVER
> 
> CAPABILITIES
> parse that for commands
> (optionally switch to Secure mode) based on this, rinse repeat 
> CAPABILITIES after switching to secure mode)
> MODE READER if above
> CAPABILITIES
> parse again
> LIST
> 
> But the clients I checked with, 3, Pan, Knode, and thunderturkey don't 
> issue CAPABILITIES.
> 
> Just issue MODE READER and go from there....
> 
> So seems that there is a diversion away from the proper route and the 
> quick route ....
> 
> Doesn't seem to be a complete definitive answer here as it seems all 
> servers and clients have gotten away from the RFC's....