Re: [NNTP] [Errata Rejected] RFC3977 (2004)

Julien ÉLIE <[email protected]> Sun, 13 May 2012 21:17:24 +0200
Newsgroups gmane.ietf.nntp
Organization TrigoFACILE -- http://www.trigofacile.com/
Message-ID <[email protected]>
Dear Barry Leiba,

I have just been aware that erratum 2004 was rejected.
Yet, I do not understand why.

> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D3977&eid=3D2004
> --------------------------------------
> Status: Rejected
> Type: Technical
>
> Reported by: Julien =C3=89lie
> Date Reported: 2010-01-14
> Rejected by: Barry Leiba (IESG)



The given reason is:

> --VERIFIER NOTES-- Section 6.2.1.2 paragraph 6 says "a previously
> valid article number MAY become invalid if the article has been
> removed". Therefore the correct response in the situation being
> addressed would be 420, not 423.
>
> This could be a case that might be considered if the document is
> updated, but certainly it's not a simple error in the document.

We are not speaking about the situation you mention.  There is a=20
difference between valid/invalid article numbers and valid/invalid=20
*current* article numbers.
Section 6.2.1.2 speaks about valid/invalid article numbers, and in this=20
situation, we are in the *second* form (article number specified) of the=20
ARTICLE command.  The possible answers are:

    Second form (article number specified)
      220 n message-id      Article follows (multi-line)
      412                   No newsgroup selected
      423                   No article with that number

The 423 response code is therefore sent here, for the second form.

In Section 6.2.1.3:

    Example of an unsuccessful retrieval of an article by number:

       [C] GROUP misc.test
       [S] 211 1234 3000234 3002322 news.groups
       [C] ARTICLE 300256
       [S] 423 No article with that number




The erratum I filled is related to the *third* form (current article=20
number used), that is to say when no article number is specified.  The=20
possible answers mentioned in RFC 3977 are:

    Third form (current article number used)
      220 n message-id      Article follows (multi-line)
      412                   No newsgroup selected
      420                   Current article number is invalid

However, the 423 response code is also a valid response code in the=20
third form.
Returning 420 in the case of a removed article is wrong because it would=20
imply that the current article number is invalid whereas it *is* valid=20
(and properly set to the article number of a removed article).

The validity of the *current* article number does not depend on the fact=20
that the article number is valid or invalid.  These are two different=20
things.

That's why the 423 response code MUST be sent in such a situation, using=20
the *third* form of the command.


Please have a look at the discussion we had in January 2010 in the IETF=20
NNTP working group.

   http://lists.eyrie.org/pipermail/ietf-nntp/2010-January/006145.html

Clive D.W. Feather (the author of RFC 3977) explains in the above=20
message the reason why 423 is a valid answer for the third form and that=20
it is "a corner case that we don't seem to have thought of" when writing=20
RFC 3977.
This code was allowed in RFC 977 (obsoleted by 3977), per Section 3.1.3=20
of RFC 977.  When the response codes were reworded to distinguish three=20
forms in RFC 3977, this corner case of 423 for the third form was=20
technically forgotten and not mentioned whereas it is the response code=20
that has *always* been implemented in NNTP servers for this situation,=20
in the third form.  No change was meant to be done in the NNTP protocol=20
by RFC 3977 about this behaviour.  It would otherwise have been=20
mentioned in Appendix D of RFC 3977!  That's why it is a genuine erratum=20
that must be considered in RFC 3977.

I am at your disposal if you need more information or have any question.

--=20
Julien =C3=89LIE

=C2=AB It's documented in The Book, somewhere=E2=80=A6 =C2=BB (Larry Wall=
)