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

From: Julien ÉLIE <[email-masked]>
Date: Sun, 13 May 2012 21:17:24 +0200

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=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

« It's documented in The Book, somewhere… » (Larry Wall)

---

From: Barry Leiba <[email-masked]>
Date: Sun, 13 May 2012 18:16:40 -0400

> 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

> We are not speaking about the situation you mention.  There is a difference
> between valid/invalid article numbers and valid/invalid *current* article
> numbers.
> 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:
>
> However, the 423 response code is also a valid response code in the third
> form.
> imply that the current article number is invalid whereas it *is* valid (and
> properly set to the article number of a removed article).
>
> 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.
>
> 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.
>

---

From: Russ Allbery <[email-masked]>
Date: Sun, 13 May 2012 17:09:08 -0700

Barry Leiba <[email-masked]> writes:

> 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 reluctantly agree.  I believe this is quite obviously an error in RFC
3977, but RFC 3977 is also quite explicit that 423 is not a permissible
response code for ARTICLE without an argument.  My understanding is that
errata can't be used to correct the clear statement of the specification,
even if that clear statement is wrong based on existing deployed code and
consistency of semantics through the specification.

> Allbery, do you have a comment on this?

Yes, please.  We would clearly want to fix this in any revision of RFC
3977.  Personally, I would recommend that any implementor use 423 as
described in Julien's analysis despite the wording of RFC 3977.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 May 2012 07:26:02 -0400

> described in Julien's analysis despite the wording of RFC 3977.

OK, that works for me.

RFC Editor, will you please switch errata #2004 from "rejected" to
"hold for document update"?  Thanks.

Barry

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 14 May 2012 23:28:39 +0200

Hi all,

[Russ]
>>> described in Julien's analysis despite the wording of RFC 3977.

[Barry]
>> "hold for document update"?  Thanks.

[Alice]
> The status has been changed as requested:
> http://www.rfc-editor.org/errata_search.php?eid=2004

And also [Clive] of course, thanks to all of you!
The "hold for document update" status is pretty fine.

[Charles]
> a revision [of RFC3977] is unlikely in the foreseeeable future. Is there
> any mechanism whereby a NOTE can be added as an erratum pointing out
> that "With hindsight it might have been better to ..., and this
> should be revisited in any revision of this document"? As least that
> would alert people to the issue and hint that they might want to
> reconsider how to cope with it in their implementation.

I do not believe such a mechanism exists.  Unfortunately.
One has to go to the HTML version of the IETF site:
     http://tools.ietf.org/html/rfc3977
and pay attention to the two red words "Errata Exist".  Then, carefully 
read through all the submitted errata.

-- 
Julien ÉLIE

« Mieux vaut allumer une bougie que maudire les ténèbres. » (Lao
   Zi)

---

From: Alice Russo <[email-masked]>
Date: Mon, 14 May 2012 09:15:59 -0400

Barry,

Thank you.
RFC Editor/ar

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 15 May 2012 14:08:02 +0100

Barry Leiba said:
> bringing up an *error* in the original spec.

To be honest, I'd forgotten that earlier discussion.

> approach, to change the erratum to "hold for document update".

I think we've all now agreed this is the right approach.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: [email-masked]     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646