[NNTP] Errata 1707 and 1527 for RFC 3977

[Julien ÉLIE <[e-mail]>]

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
on section 3.2.1 without any corrected text -- now we have a corrected
text, for 3.4.2).  In fact, I did not know where to put my remark when
I first submitted the bug report.  Clive found a place in RFC 3977
to put it directly in the text, which is far better!


The following sections should be changed (with line breaks removed
in the notes section only, because they are otherwise put at wrong
places in the web version):

Section
-------
3.4.2

Original Text
-------------
However, the server MAY cease to advertise the MODE-READER
capability after the client uses any command except CAPABILITIES.

Corrected Text
--------------
If the client uses a command which will be available in reading mode
and the server will continue to advertise the MODE-READER capability
after responding to that command, the response code 401, with
MODE-READER as the first argument, MUST be returned.  However, the
server MAY cease to advertise the MODE-READER capability after the
client uses any command except CAPABILITIES, in which case the
response code 502 MUST be returned for such commands.

Notes
-----
Here are two examples to illustrate Section 5.3.3 with that clarification.

Example of the 401 response code to indicate that MODE READER is needed:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] MODE-READER
   [S] .
   [C] POST
   [S] 401 MODE-READER
   [C] MODE READER
   [S] 200 Reader mode, posting permitted
   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] READER
   [S] LIST ACTIVE NEWSGROUPS
   [S] POST
   [S] .

Example of a mode-switching server which does not allow any reader
command to be used, even unsuccessfully, in transit mode:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] MODE-READER
   [S] .
   [C] POST
   [S] 502 Transit service only
   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] .
   [C] MODE READER
   [S] 502 Transit service only
   [Server closes connection.]






Many thanks beforehand,

-- 
Julien ÉLIE

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

--- Begin Message ---

Hi,

The rationale for which erratum 1707 for RFC 3977 was "Rejected"
<http://www.rfc-editor.org/errata_search.php?eid=1707> is:

    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.


I post it here for the archives (because there is currently no public
trace of the rationale Clive judiciously gave).

Note that the erratum was previously marked as held for document update
but that is currently no longer the case, which is right.  This
erratum must not be verified.

Julien


----- Message d'origine ----- 
De : "RFC Errata System"
À : Clive, Chris, Lisa, Ned, Russ
Cc : Julien, RFC Editor
Envoyé : lundi 23 novembre 2009 22:14
Objet : [Errata Held for Document Update] RFC3977 (1707)


>
> The following errata report has been held for document update
> for RFC3977, "Network News Transfer Protocol (NNTP)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3977&eid=1707
>
> --------------------------------------
> Status: Held for Document Update
> Type: Technical
>
> Reported by: Julien Élie
> Date Reported: 2009-03-05
> Held by: Lisa Dusseault (IESG)
>
> Section: 6.1.1.2
>
> Original Text
> -------------
> The successful selection response will return the article numbers of
> the first and last articles in the group at the moment of selection
> (these numbers are referred to as the "reported low water mark" and
> the "reported high water mark") and an estimate of the number of
> articles in the group currently available.
>
> Corrected Text
> --------------
> The successful selection response will return the article numbers of
> the first and last articles in the group at the moment of selection
> (these numbers are referred to as the "reported low water mark" and
> the "reported high water mark" when the group is not empty) and an
> estimate of the number of articles in the group currently available.
>
>
> Notes
> -----
> The notion of "first and last articles" does not exist when a newsgroup is empty. 
> The meaning of the "reported low water mark" and the "reported high water mark" is 
> explained in a special paragraph afterwards.
>
> To be more precise, if at a given time we have only one article in misc.test and 
> the following answer to a GROUP command:
>
>      [C] GROUP misc.test
>      [S] 211 1 12 12 misc.test
>
> After cancelling this article, the same GROUP command SHOULD give:
>
>      [C] GROUP misc.test
>      [S] 211 0 13 12 misc.test
>
> The low water mark is one more than the high water mark (that is to say that the 
> low water mark has increased, and the high water mark has not decreased).  It will 
> permit the following article arrival to be handled by incrementing the high water 
> mark and leaving the low water mark unchanged.
>
> --------------------------------------
> RFC3977 (draft-ietf-nntpext-base-27)
> --------------------------------------
> Title               : Network News Transfer Protocol (NNTP)
> Publication Date    : October 2006
> Author(s)           : C. Feather
> Category            : PROPOSED STANDARD
> Source              : NNTP Extensions
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
> 

--- End Message ---

--- Begin Message ---

Hi,

As erratum 1527 for RFC 3977 was put in the "Held for Document Update"
state <http://www.rfc-editor.org/errata_search.php?eid=1527>, here
is the preferred wording that Clive suggested but that we unfortunately
could not put in the final erratum.

I post it here for the archives (because there is currently no public
trace of that new wording), so that it could be properly reviewed
when the NNTP protocol moves from proposed standard to draft standard.


-----------------------------------------------------------------------
RFC 3977 - Erratum 1527
-----------------------------------------------------------------------

It should be VERIFIED.

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
on section 3.2.1 without any corrected text -- now we have a corrected
text, for 3.4.2).  In fact, I did not know where to put my remark when
I first submitted the bug report.  Clive found a place in RFC 3977
to put it directly in the text, which is far better!

The following sections should be changed (with line breaks removed
in the notes section only, because they are otherwise put at wrong
places in the web version):

Section
-------
3.4.2

Original Text
-------------
However, the server MAY cease to advertise the MODE-READER
capability after the client uses any command except CAPABILITIES.

Corrected Text
--------------
If the client uses a command which will be available in reading mode
and the server will continue to advertise the MODE-READER capability
after responding to that command, the response code 401, with
MODE-READER as the first argument, MUST be returned.  However, the
server MAY cease to advertise the MODE-READER capability after the
client uses any command except CAPABILITIES, in which case the
response code 502 MUST be returned for such commands.

Notes
-----
Here are two examples to illustrate Section 5.3.3 with that clarification.

Example of the 401 response code to indicate that MODE READER is needed:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] MODE-READER
   [S] .
   [C] POST
   [S] 401 MODE-READER
   [C] MODE READER
   [S] 200 Reader mode, posting permitted
   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] READER
   [S] LIST ACTIVE NEWSGROUPS
   [S] POST
   [S] .

Example of a mode-switching server which does not allow any reader
command to be used, even unsuccessfully, in transit mode:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] MODE-READER
   [S] .
   [C] POST
   [S] 502 Transit service only
   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] .
   [C] MODE READER
   [S] 502 Transit service only
   [Server closes connection.]






----- Message d'origine ----- 
De : RFC Errata System
À : Clive, Chris, Lisa, Ned, Russ
Cc : Julien, RFC Editor
Envoyé : mercredi 24 septembre 2008 19:34
Objet : [Technical Errata Reported] RFC3977 (1527)


>
> The following errata report has been submitted for RFC3977,
> "Network News Transfer Protocol (NNTP)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3977&eid=1527
>
> --------------------------------------
> Type: Technical
> Reported by: Julien Élie
>
> Section: 3.2.1
>
> Original Text
> -------------
> 401: The client must change the state of the connection in some other
>   manner.  The first argument of the response MUST be the capability
>   label (see Section 5.2) of the facility that provides the
>   necessary mechanism (usually an extension, which may be a private
>   extension).  The server MUST NOT use this response code except as
>   specified by the definition of the capability in question.
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> The 401 code is never dealt with in the whole RFC 3977.  Even the definition of 
> the MODE-READER capability does not indicate when the 401 return code should be 
> used.
> It should be said that it MUST be used in answers to commands only available after 
> having sent MODE READER.  Maybe section 5.3.2 that described the MODE READER 
> command, is the right place to use in order to specify that behaviour.
>
> [C] CAPABILITIES
> [S] 101 Capability list:
> [S] VERSION 2
> [S] IHAVE
> [S] MODE-READER
> [S] .
> [C] POST
> [S] 401 MODE-READER
> [C] MODE READER
> [S] 200 Reader mode, posting permitted
> [C] CAPABILITIES
> [S] 101 Capability list:
> [S] VERSION 2
> [S] READER
> [S] POST
> [S] .
> [C] POST
> [S] 340 Input article; end with <CR-LF>.<CR-LF>
> [C] From: "Demo User" <[e-mail]>
> [C] Newsgroups: misc.test
> [C] Subject: I am just a test article
> [C] Organization: An Example Net
> [C]
> [C] This is just a test article.
> [C] .
> [S] 240 Article received OK
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC3977 (draft-ietf-nntpext-base-27)
> --------------------------------------
> Title               : Network News Transfer Protocol (NNTP)
> Publication Date    : October 2006
> Author(s)           : C. Feather
> Category            : PROPOSED STANDARD
> Source              : NNTP Extensions
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
> 

--- End Message ---