[NNTP] Errata 1707 and 1527 for RFC 3977
Julien ÉLIE <[email protected]> Mon, 14 May 2012 23:41:35 +0200
| Newsgroups | gmane.ietf.nntp |
|---|---|
| Organization | TrigoFACILE -- http://www.trigofacile.com/ |
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------060901060601060507060507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi Barry,
As I see that you are currently pretty active on errata for RFC 3977, I=20
believe it could be time to properly close the two remaining subjects=20
that weren't updated two years ago.
* Could the following rationale be added to erratum 1707 for RFC 3977 so=20
as to explain the reason of the reject?
http://www.rfc-editor.org/errata_search.php?eid=3D1707
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=20
"VERIFIED" so that it could be properly reviewed when the NNTP protocol=20
moves from proposed standard to draft standard?
http://www.rfc-editor.org/errata_search.php?eid=3D1527
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,
--=20
Julien =C9LIE
=AB Mieux vaut allumer une bougie que maudire les t=E9n=E8bres. =BB (Lao
Zi)
--------------060901060601060507060507
Content-Type: message/rfc822;
name="Message joint"
Content-Disposition: attachment;
filename="Message joint"
Content-Transfer-Encoding: 7bit
X-Mozilla-Keys:
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 23 Jan 2010 12:58:56 -0000
Received: from hope.eyrie.org (166.84.7.155)
by mx0.ovh.net with SMTP; 23 Jan 2010 12:58:56 -0000
Received: from hope.eyrie.org (localhost [127.0.0.1])
by hope.eyrie.org (Postfix) with ESMTP id A5B4567E60
for <[email protected]>; Sat, 23 Jan 2010 04:58:55 -0800 (PST)
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213])
by hope.eyrie.org (Postfix) with SMTP id 9D2AF67D9D
for <[email protected]>; Sat, 23 Jan 2010 04:58:53 -0800 (PST)
Received: (qmail 1274 invoked by uid 503); 23 Jan 2010 12:59:02 -0000
Received: from b7.ovh.net (HELO mail436.ha.ovh.net) (213.186.33.57)
by 30.mail-out.ovh.net with SMTP; 23 Jan 2010 12:59:01 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
by b0.ovh.net with SMTP; 23 Jan 2010 12:58:52 -0000
Received: from aaubervilliers-151-1-29-164.w83-112.abo.wanadoo.fr (HELO
Iulius) (julien%[email protected])
by ns0.ovh.net with SMTP; 23 Jan 2010 12:58:51 -0000
Message-ID: <81F509814C884A988687249A804C8A6A@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[email protected]>
To: <[email protected]>
Date: Sat, 23 Jan 2010 13:58:51 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252";
reply-type=original
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 17477062780172238215
X-Ovh-Remote: 83.112.20.164
(aaubervilliers-151-1-29-164.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Subject: [NNTP] Tr: [Errata Held for Document Update] RFC3977 (1707) --
archive of rationale
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: NNTP protocol discussion <ietf-nntp.lists.eyrie.org>
List-Unsubscribe: <http://lists.eyrie.org/mailman/options/ietf-nntp>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.eyrie.org/pipermail/ietf-nntp>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.eyrie.org/mailman/listinfo/ietf-nntp>,
<mailto:[email protected]?subject=subscribe>
Sender: [email protected]
Errors-To: [email protected]
X-Ovh-Tracer-Id: 17478470155541129214
X-Ovh-Remote: 166.84.7.155 (hope.eyrie.org)
X-Ovh-Local: 213.186.33.32 (mx0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Content-Transfer-Encoding: quoted-printable
Hi,
The rationale for which erratum 1707 for RFC 3977 was "Rejected"
<http://www.rfc-editor.org/errata_search.php?eid=3D1707> 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 -----=20
De : "RFC Errata System"
=C0 : Clive, Chris, Lisa, Ned, Russ
Cc : Julien, RFC Editor
Envoy=E9 : 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=3D3977&eid=3D1707
>
> --------------------------------------
> Status: Held for Document Update
> Type: Technical
>
> Reported by: Julien =C9lie
> 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.=20
> The meaning of the "reported low water mark" and the "reported high wat=
er mark" is=20
> explained in a special paragraph afterwards.
>
> To be more precise, if at a given time we have only one article in misc=
.test and=20
> 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=20
> low water mark has increased, and the high water mark has not decreased=
). It will=20
> permit the following article arrival to be handled by incrementing the =
high water=20
> 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
>=20
--------------060901060601060507060507
Content-Type: message/rfc822;
name="Message joint"
Content-Disposition: attachment;
filename="Message joint"
Content-Transfer-Encoding: 7bit
X-Mozilla-Keys:
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 23 Jan 2010 12:49:02 -0000
Received: from hope.eyrie.org (166.84.7.155)
by mx0.ovh.net with SMTP; 23 Jan 2010 12:49:00 -0000
Received: from hope.eyrie.org (localhost [127.0.0.1])
by hope.eyrie.org (Postfix) with ESMTP id F2C5D67E14
for <[email protected]>; Sat, 23 Jan 2010 04:48:59 -0800 (PST)
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213])
by hope.eyrie.org (Postfix) with SMTP id 92B1467E0A
for <[email protected]>; Sat, 23 Jan 2010 04:48:57 -0800 (PST)
Received: (qmail 24814 invoked by uid 503); 23 Jan 2010 12:49:05 -0000
Received: from b7.ovh.net (HELO mail436.ha.ovh.net) (213.186.33.57)
by 30.mail-out.ovh.net with SMTP; 23 Jan 2010 12:49:05 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
by b0.ovh.net with SMTP; 23 Jan 2010 12:48:56 -0000
Received: from aaubervilliers-151-1-29-164.w83-112.abo.wanadoo.fr (HELO
Iulius) (julien%[email protected])
by ns0.ovh.net with SMTP; 23 Jan 2010 12:48:52 -0000
Message-ID: <0FFC6AD152234D1E886C1DD2F4CAABCA@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[email protected]>
To: <[email protected]>
Date: Sat, 23 Jan 2010 13:48:52 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252";
reply-type=original
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 17308459269698682247
X-Ovh-Remote: 83.112.20.164
(aaubervilliers-151-1-29-164.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Subject: [NNTP] Tr: [Technical Errata Reported] RFC3977 (1527) -- archive
for draft standard
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: NNTP protocol discussion <ietf-nntp.lists.eyrie.org>
List-Unsubscribe: <http://lists.eyrie.org/mailman/options/ietf-nntp>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.eyrie.org/pipermail/ietf-nntp>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.eyrie.org/mailman/listinfo/ietf-nntp>,
<mailto:[email protected]?subject=subscribe>
Sender: [email protected]
Errors-To: [email protected]
X-Ovh-Tracer-Id: 17310711067950360574
X-Ovh-Remote: 166.84.7.155 (hope.eyrie.org)
X-Ovh-Local: 213.186.33.32 (mx0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Content-Transfer-Encoding: quoted-printable
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=3D1527>, 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 -----=20
De : RFC Errata System
=C0 : Clive, Chris, Lisa, Ned, Russ
Cc : Julien, RFC Editor
Envoy=E9 : 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=3D3977&eid=3D1527
>
> --------------------------------------
> Type: Technical
> Reported by: Julien =C9lie
>
> 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 defin=
ition of=20
> the MODE-READER capability does not indicate when the 401 return code s=
hould be=20
> used.
> It should be said that it MUST be used in answers to commands only avai=
lable after=20
> having sent MODE READER. Maybe section 5.3.2 that described the MODE R=
EADER=20
> 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" <[email protected]>
> [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
>=20
--------------060901060601060507060507--