[NNTP] [Errata Rejected] RFC3977 (2004)

[Barry Leiba]

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

Well, the response in the rejection reason is taken directly from an
exchange I had with Clive.  Now, he did also suggest that I might pass
it by Russ Allbery, which I have not yet done.  Since he's copied on
this exchange, he can comment.  Clive's point wasn't meant to say that
your suggestion in the errata report wasn't good, but that it's not
bringing up an *error* in the original spec.  If what you suggest is
an appropriate change, it might be considered if there's work done to
revise the document.

I'd be happy, if Clive, Russ, and Julien all think it's the right
approach, to change the erratum to "hold for document update".  Russ
Allbery, do you have a comment on this?

Barry Leiba, Applications Area Director

>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3977&eid=2004
>> --------------------------------------
>> Status: Rejected
>> Type: Technical
>>
>> Reported by: Julien Élie
>> 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 difference
> between valid/invalid article numbers and valid/invalid *current* article
> numbers.
> Section 6.2.1.2 speaks about valid/invalid article numbers, and in this
> situation, we are in the *second* form (article number specified) of the
> 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 number
> used), that is to say when no article number is specified.  The 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 third
> form.
> Returning 420 in the case of a removed article is wrong because it would
> imply that the current article number is invalid whereas it *is* valid (and
> properly set to the article number of a removed article).
>
> The validity of the *current* article number does not depend on the fact
> that the article number is valid or invalid.  These are two different
> things.
>
> That's why the 423 response code MUST be sent in such a situation, using the
> *third* form of the command.
>
>
> Please have a look at the discussion we had in January 2010 in the IETF 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 message
> the reason why 423 is a valid answer for the third form and that it is "a
> corner case that we don't seem to have thought of" when writing RFC 3977.
> This code was allowed in RFC 977 (obsoleted by 3977), per Section 3.1.3 of
> RFC 977.  When the response codes were reworded to distinguish three forms
> in RFC 3977, this corner case of 423 for the third form was technically
> forgotten and not mentioned whereas it is the response code that has
> *always* been implemented in NNTP servers for this situation, in the third
> form.  No change was meant to be done in the NNTP protocol by RFC 3977 about
> this behaviour.  It would otherwise have been mentioned in Appendix D of RFC
> 3977!  That's why it is a genuine erratum that must be considered in RFC
> 3977.
>
> I am at your disposal if you need more information or have any question.
>
> --
> Julien ÉLIE