headers
Julien ÉLIE | 13 May 2012 21:17
Favicon

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

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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Barry Leiba | 14 May 2012 00:16
Picon
Favicon
Gravatar

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

> 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)
>
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Russ Allbery | 14 May 2012 02:09
Picon
Favicon
Gravatar

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

Barry Leiba <barryleiba <at> computer.org> writes:

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

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

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 (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Charles Lindsey | 14 May 2012 12:00
Picon
Picon

Re: [NNTP] Babble from Russ Allbery <rra <at> stanford.edu>

Russ Allbery <rra <at> stanford.edu> writes:

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

Yes, but a revision 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.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131            Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Barry Leiba | 14 May 2012 13:26
Picon
Favicon
Gravatar

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

>> 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?
>
> 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.

OK, that works for me.

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

Barry
Permalink | Reply | 2 comments |
headers
Julien ÉLIE | 14 May 2012 23:28
Favicon

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

Hi all,

[Russ]
>>> 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.

[Barry]
>> RFC Editor, will you please switch errata #2004 from "rejected" to
>> "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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien ÉLIE | 14 May 2012 23:41
Favicon

[NNTP] Errata 1707 and 1527 for RFC 3977

Hi Barry,

As I see that you are currently pretty active on errata for RFC 3977, I 
believe it could be time to properly close the two remaining subjects 
that weren't updated two years ago.

* Could the following rationale be added to erratum 1707 for RFC 3977 so 
as to explain the reason of the reject?

http://www.rfc-editor.org/errata_search.php?eid=1707

    The high water mark is one less than the low water mark for empty
    newsgroups.  A major reason for doing it this way was to deal with
    clusters of servers.  If they're not perfectly synchronized, then
    a cancel might be visible on one and not another.  So if you connect
    to the second one, it looks as if the article has been reinstated.
    Wording it like this meant we didn't need special treatment of such
    clusters.  The low water mark cannot decrease.  [Clive D.W. Feather]

* Could erratum 1527 for RFC 3977 be updated and its status changed to 
"VERIFIED" so that it could be properly reviewed when the NNTP protocol 
moves from proposed standard to draft standard?

http://www.rfc-editor.org/errata_search.php?eid=1527

The new wording is better than what was originally suggested as
erratum.  **It fixes exactly the same issue.**
You can see that the current erratum about section 3.2.1 deals with
MODE-READER.  It appeared after discussing with Russ and Clive that
it was better to change section 3.4.2 (mine was just a remark
(Continue reading)

Permalink | Reply | 5 comments |
headers
Alice Russo | 14 May 2012 15:15

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

Barry,

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

Thank you.
RFC Editor/ar

On May 14, 2012, at 7:26 AM, Barry Leiba wrote:

>>> 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?
>> 
>> 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.
> 
> OK, that works for me.
> 
> RFC Editor, will you please switch errata #2004 from "rejected" to
> "hold for document update"?  Thanks.
> 
> Barry
>
Permalink | Reply | 1 comment |
headers
Clive D.W. Feather | 15 May 2012 13:07

Re: [NNTP] Interoperability with 502 answer to GROUP command

Julien LIE said:
> We had a question on inn-workers about the response code a news server
> should give to a GROUP command for an existing newsgroup to which the
> client does not have access:
>    https://lists.isc.org/pipermail/inn-workers/2010-September/017275.html

Hi,

Found this while looking into the errata.

> It appears that INN answers 480/502 (depending on the state of 
> authentication)
> but a few news clients (amongst them are tin and Thunderbird) immediately
> close the connection.
> As a matter of fact, according to RFC 3977:
> 
>   502:  It is necessary to terminate the connection and to start a new
>                            ^^^^^^^^^^^^^^^^^^^^^^^^
>         one with the appropriate authority before the command can be used.

That's for a *command*, not for a specific set of parameters.

> Suppose we have three groups on a news server :
> * group.public, readable by everybody
> * group.auth1, readable by user1
> * group.auth2, readable by user2
> 
> Are the following answers the right ones?
> 
> 200 Hello!
(Continue reading)

Permalink | Reply | 2 comments |
headers
Clive D.W. Feather | 15 May 2012 14:04

[NNTP] Errata 1522 and 2719 for RFC 3977

I'm not clear why these are Held for Document Update - they should be
Verified.

--

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive <at> davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646
Permalink | Reply | 2 comments |

Gmane