[NNTP] Issue with IHAVE/CHECK/TAKETHIS in RFC

[Julien ÉLIE]

Hi Clive,

>> I believe there is a major issue with the handling of the 501 answer code.
>>
>> According to RFC 3977, the following schema is correct:
>>
>>  [S] IHAVE <a b c
>>  [C] 501 Bad Message-ID
>
> Correct.

We both agree that 501 is the code RFC 3977 reckons to be sent.



>> Thus, implementing RFC 3977 breaks current implementations.
>
> I disagree. If you look at RFC 977, section 2.4.3, you will see the same
> rule: a syntax error in *any* command results in a 501.

RFCs 977 and 2980 are wrong in lots of places.



>> As for IHAVE, the only possible answer here is 435; on no account
>> should 501 be sent.
>
> I disagree. 435 means "not wanted", not "invalid syntax".

I understand that 435 means "not wanted".  However, news servers have
*always* been written and are *still* written to use "not wanted"
for IHAVE/CHECK/TAKETHIS commands when something is wrong.

That *essential* fact is not mentioned in RFCs 3977 and 4644.


Why new news servers cannot use 501?  Well, if they try, they will
see within a few days that they do not receive any new articles
from lots of other news servers.

(I was proposed <4ac9a2d6$0$21410$afc38c87@> on October, 5th 2009
-- which is a bad message-ID.)



Besides, where is it specified in RFC 4644 that, for CHECK/TAKETHIS,
the wrong argument provided is to be returned after 501?

We properly have:

[C] CHECK <abc at test>
[S] 238 <abc at test>

But never is it said:

[C] CHECK bad mid
[S] 501 bad mid


Maybe it is worthless but it is not consistent to have the provided
argument in CHECK/TAKETHIS for only a subset of answers, especially
when pipelining is used and some news servers expect the provided
argument to be present in the answer...

      [C] CHECK <i.am.an.article.you.will.want at example.com>
      [C] CHECK i am a nasty article
      [C] CHECK <i.am.an.article.you.defer at example.com>
      [S] 238 <i.am.an.article.you.will.want at example.com>
      [S] 501 Invalid syntax
      [S] 431 <i.am.an.article.you.defer at example.com>

is not cool.



>> It appears that a few commands require that no check is done on their
>> syntax, and it is not mentioned in RFC 3977.
>
> Nor is it mentioned in RFC 977, nor was it *EVER* mentioned in many years
> of discussion leading up to 3977.
>
>
>>> Do you have an idea of what it is possible to do as for that issue?
>
> Not easily. You need to decide if you want to work with broken software.

So, if I understand well, we need to decide if we want to work with INN,
Diablo and Dnews? :)


INN 1 (yes, version 1 -- and the same is in version 2):
-------------------------------------------------------

200 feed-A.news.volia.net InterNetNews server INN 1.7.2 (FAST switching patch) ready
IHAVE test
435 test Bad Message-ID

Diablo:
-------

200 news1.greatnowhere.com NNTP Service Ready (DIABLO 5.0-REL)
IHAVE test
435 test Bad Message-ID

DNEWS:
------

200 mendel.ac-versailles.fr DNEWS Version  5.7e1,, S0, posting OK
IHAVE test
435 article not wanted - Missing opening angle bracket
CHECK test
438 test article not wanted - Missing opening angle bracket




Well, in practice, what should we do now?
It is patent that we cannot implement RFC 3977/4644 as-is for IHAVE/CHECK/TAKETHIS
*without actually breaking article propagation*.  Articles are stuck forever in
the queue for INN and Diablo if 501 is returned; no new articles are propagated.


I believe:
 * that behaviour should be said (erratum? new RFC?) because it is currently
   breaking Usenet;
 * current software should be patched to properly understand 501 and other codes
   that can possibly be sent, so that they do not block upon receiving these
   unexpected codes;
 * in several years, we may consider sending 501 and other error codes.

Or another possibility is to send 501 and other error codes only if the client
has previously sent CAPABILITIES in the session.  We could then be "confident"
that it knows how to deal with 501 and other error codes.


What's the best move you see?
Something must be decided and done; otherwise RFC 3977/4644 are breaking
existing widely-spread NNTP implementations.

-- 
Julien ÉLIE

« Memoriam quoque ipsam cum uoce perdidissemus,
  si tam in nostra potestate esset obliuisci quam tacere. »
  (Tacite, _Vie d'Agricola_)