RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 28 records.

Status: Verified (12)

RFC 4707, "Netnews Administration System (NAS)", October 2006

Source of RFC: INDEPENDENT

Errata ID: 5813
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.1.1 says:

   Answer = response-code [answertext] CRLF
            text CRLF
            "." CRLF

It should say:

   answer = response-code [answertext] CRLF
            *(text CRLF)
            "." CRLF

Notes:

There may be zero, one or more additional lines of text followed by a CRLF.

Errata ID: 5815
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.1 says:

   help-answer =  "410" [answertext] CRLF
                  text CRLF
                  "." CRLF
   help-answer =/ "100" [answertext] CRLF
                  text CRLF
                  "." CRLF

It should say:

   help-answer =  "410" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   help-answer =/ "100" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

Notes:

Per the examples shown, it is clear that zero, one, or more lines of text may be supplied.

Errata ID: 5816
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.2 says:

   info-answer =  "400" [answertext] CRLF
                  text CRLF
                  "." CRLF
   info-answer =/ "101" [answertext] CRLF
                  text CRLF
                  "." CRLF

It should say:

   info-answer =  "400" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   info-answer =/ "101" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

Notes:

Per the examples shown in the text, it is clear that a response may include zero, one, or many additional lines of text.

Errata ID: 5821
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.6 says:

   The data consist of a newsgroup- or hierarchy-name/status indicator
   pair per line.  Name and status indicator must be separated by at
   least one white space.
[...]
   listdata    =  name WSP list-status

It should say:

   The data consist of a newsgroup- or hierarchy-name/status indicator
   pair per line.  Name and status indicator must be separated by at
   least one white space.
[...]
   listdata    =  name 1*WSP list-status

Notes:

Only one white space is allowed in the definition of listdata. I suggest allowing several WSP for consistency with the description.
Same remark for the definition of listdata in Section 6.3.3.7 (LSTR command).

Errata ID: 5822
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.6 says:

   list-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF
   list-answer =/ "510" [answertext] CRLF
                   text CRLF
                   "." CRLF

It should say:

   list-answer =/ "401" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   list-answer =/ "510" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

Notes:

Zero, one, or more lines of text are allowed.

Errata ID: 5823
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.7 says:

   lstr-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF
   lstr-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF

It should say:

   lstr-answer =/ "401" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   lstr-answer =/ "510" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

Notes:

Zero, one, or more lines of text are allowed.

Errata ID: 5834
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 11 says:

    Mod-Sub-Adr      no           N    no         Submission address

It should say:

    Mod-Sub-Adr      no           N    yes        Submission address

Notes:

This header is repeatable, as stated in its definition in Section 6.3.4.
A newsgroup may have several e-mails to be reached.

Errata ID: 5836
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 11 says:

    Article-Length   no           H    no         Article length

It should say:

    Article-Length   no          H/N    no        Article length

Notes:

As stated in the definition of Article-Length in Section 6.3.4, it also applies to newsgroups.

Errata ID: 5841
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-19
Verifier Name: Adrian Farrel
Date Verified: 2019-09-01

Section 6.3.3 says:

   text          = %d1-9 /           ; all octets except
                   %d11-12 /         ; US-ASCII NUL, CR and LF
                   %d14-255

It should say:

   text          = *(%d1-9 /         ; all octets except
                     %d11-12 /       ; US-ASCII NUL, CR and LF
                     %d14-255)

Notes:

Each time the "text" keyword is used in ABNF definitions in this RFC, it means "any number, including none, of octets except NUL, CR and LF" and not one such octet.

Errata ID: 5826
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.10 says:

   <-- GETP 0 0 0 humanities
   --> 615 data follow

It should say:

   <-- GETP 0 0 0 humanities
   --> 613 data follow

Notes:

Section 10 and also getp-answer in Section 6.3.3.10 indicates a 613 response code for GETP.

Errata ID: 5827
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.3.11 says:

   <-- GETA 0 0 0 humanities
   --> 613 data follow

It should say:

   <-- GETA 0 0 0 humanities
   --> 615 data follow

Notes:

Section 10 and also geta-answer in Section 6.3.3.11 indicates a 615 response code for GETA.

Errata ID: 5831
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Verifier Name: Adrian Farrel
Date Verified: 2019-08-18

Section 6.3.4 says:

   Serial

   Header:      Serial

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for hierarchy data.
   Comment:     For a detailed description, see Section 6.4.
   Example:     Serial: 20020821102413

   Used for:    newsgroup
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for newsgroup data.
   Comment:     For a detailed description, see Section 6.4.
   Example:     Serial: 20020821102413

It should say:

   Serial

   Header:      Serial

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for hierarchy data.
   Comment:     For a detailed description, see Section 6.3.3.10.
   Example:     Serial: 20020821102413

   Used for:    newsgroup
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for newsgroup data.
   Comment:     For a detailed description, see Section 6.3.3.10.
   Example:     Serial: 20020821102413

Notes:

Its use as a timestamp is described in Section 6.3.3.10, for both hierarchies and newsgroups.

Status: Reported (7)

RFC 4707, "Netnews Administration System (NAS)", October 2006

Source of RFC: INDEPENDENT

Errata ID: 5817
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18

Section 6.3.3.3 says:

   date-answer =  "511" [answertext] CRLF
                  text CRLF
                  "." CRLF

It should say:

   date-answer =  "511" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

Notes:

I suggest [1*text CRLF] that is to say a possible non-empty line.
We need at least *text anyway (several characters), as shown in the example in Section 6.3.3.3.

Errata ID: 5820
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18

Section 6.3.3.5 says:

   quit-answer = "201" [answertext] CRLF

It should say:

   quit-answer = "201" [answertext] CRLF
                 [1*text CRLF]
                 "." CRLF

Notes:

The QUIT command is the only one whose answer does not follow the general ABNF description of answers requiring them to end with a ("." CRLF) line.
I suggest either fixing quit-answer to the above corrected text, or modifying Section 6.1.1 to take into account a special case for QUIT.

Errata ID: 5824
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18

Throughout the document, when it says:

Section 6.3.3.8:

   hier-answer =/ "510" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   hier-answer =/ "401" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

   hierdata    =  "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Section 6.3.3.9:

   data-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF
   data-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF

   datadata    =  "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

It should say:

Section 6.3.3.8:

   hier-answer =/ "510" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   hier-answer =/ "401" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

   hierdata    =  "Name:" WSP name CRLF
                  "Status:" WSP list-status CRLF
                  *(header ":" WSP *text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Section 6.3.3.9:

   data-answer =/ "510" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   data-answer =/ "401" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

   datadata    =  "Name:" WSP name CRLF
                  "Status:" WSP list-status CRLF
                  *(header ":" WSP *text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Notes:

I suggest [1*text CRLF], that is to say a possible non-empty line, for hier-answer and data-answer with 501 or 401 response codes.
We need at least *text anyway (several characters), as shown in the examples in Section 6.3.3.8 and 6.3.3.9.

As for hierdata and datadata, the text keyword used thrice alone is also not right.

Errata ID: 5825
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18

Throughout the document, when it says:

Section 6.3.3.10:

   username =  *1( VCHAR ) / "0" ; Length of VCHAR >= 1

   password =  *1( VCHAR ) / "0" ; Length of VCHAR >= 1

[...]

   getp-answer =/ "213" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "430" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "411" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF

   getpdata   =   "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Section 6.3.3.11:

   geta-answer =/ "215" [answertext] CRLF
                   text CRLF
                   "." CRLF
   geta-answer =/ "430" [answertext] CRLF
                  text CRLF
                  "." CRLF
   geta-answer =/ "411" [answertext] CRLF
                  text CRLF
                  "." CRLF
   geta-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF

   getadata   =   "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer/
                    "Mod-PGP-Key:" CRLF PGP-answer)]

It should say:

Section 6.3.3.10:

   username =  1*VCHAR / "0"

   password =  1*VCHAR / "0"

[...]

   getp-answer =/ "213" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   getp-answer =/ "430" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   getp-answer =/ "411" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   getp-answer =/ "510" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

   getpdata   =   "Name:" WSP name CRLF
                  "Status:" WSP list-status CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP *text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Section 6.3.3.11:

   geta-answer =/ "215" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   geta-answer =/ "430" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   geta-answer =/ "411" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF
   geta-answer =/ "510" [answertext] CRLF
                  [1*text CRLF]
                  "." CRLF

   getadata   =   "Name:" WSP name CRLF
                  "Status:" WSP list-status CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP *text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

Notes:

For username and password, RFC 4234 defines VCHAR as %x21-7E, that is to say only one character.

I suggest [1*text CRLF], that is to say a possible non-empty line, for getp-answer and geta-answer with 213, 215, 430, 411 and 510 response codes.
We need at least *text anyway (several characters), as shown in the examples in Sections 6.3.3.10 and 6.3.3.11.

As for getpdata and getadata, the text keyword used thrice alone is also not right.

Errata ID: 5833
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Edited by: Adrian Farrel
Date Edited: 2019-08-18

Section 6.3.4 says:

   Header: Source

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no

It should say:

   Header: Source

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes

Notes:

This header is repeatable, as stated in Section 11.

However, it is currently unclear whether section 6.3.4 is correct (note use of the singular in the explanatory text) of whether section 11 is correct.

Errata ID: 5835
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18

Section 6.7 says:

   PGP keys for Ctrl-PGP-Key and Mod-PGP-Key are transmitted in the
   following structure:

   PGP-answer = "V" SP Version CRLF
                "U" SP User-ID CRLF
                "B" SP Bits CRLF
                "I" SP Key-ID CRLF
                "F" SP Finger CRLF
                *("L" SP Location CRLF)
                *("K-" Keyblock CRLF)
                "K" SP Keyblock CRLF

   Version  = text
   User-ID  = text
   Bits     = text
   Key-ID   = text
   Finger   = text
   Location = text
   Keyblock = text

It should say:

   PGP keys for Ctl-PGP-Key and Mod-PGP-Key are transmitted in the
   following structure:

   PGP-answer = [*("U" SP User-ID CRLF)]
                ["B" SP Bits CRLF]
                ["I" SP Key-ID CRLF]
                [*("L" SP Location CRLF)]
                ["F" SP Finger CRLF]
                "V" SP Version CRLF
                1*("K-" Keyblock CRLF)
                "K" SP Keyblock CRLF

   Version  = 1*text
   User-ID  = 1*text
   Bits     = 1*text
   Key-ID   = 1*text
   Finger   = 1*text
   Location = 1*text
   Keyblock = 1*text

Notes:

Several fixes :
1- Spelling of "Ctl-PGP-Key" at the first line.
2- Several UIDs are possible for a given key.
3- We need several characters (text is only a byte, so use 1*text).
4- Only Version and Keyblocks are mandatory.
5- Re-arrange the lines of PGP-answer to match the example in the same Section.

Errata ID: 5837
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18

Section 6.1.2 says:

   Answers of the type 1xx, 2xx, 4xx, and
   5xx can have a text after the numerical code.  3xx answers contain
   one or more parameters with data; the exact format is explained in
   the description of the commands.

Notes:

These sentences are not clear.
I suggest to just remove them, or reformulate them if they really have importance.
The 202 response code for VERS also has a parameter with data (the current protocol level) for instance.
And 6xx response codes are not mentioned.

Status: Held for Document Update (7)

RFC 4707, "Netnews Administration System (NAS)", October 2006

Source of RFC: INDEPENDENT

Errata ID: 5811
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 2 says:

   The organizational structure of NAS is hierarchical; this means that
   a NAS root server collects data from the sub-servers that are
   authoritative for certain hierarchies.

It should say:

   The organizational structure of NAS is hierarchical; this means that
   an NAS root server collects data from the sub-servers that are
   authoritative for certain hierarchies.

Notes:

For consistency throughout the document, spell "an NAS root server" instead of "a NAS root server".

Errata ID: 5812
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 4 says:

   An attached time stamp makes it possible to distinguish between
   new and old data and to avoid loops in the propagation.

It should say:

   An attached timestamp makes it possible to distinguish between
   new and old data and to avoid loops in the propagation.

Notes:

For consistency throughout the document, spell "timestamp" instead of "time stamp".

Errata ID: 5818
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.3.4 says:

   This version number MUST not be higher
   than that requested by the client.

It should say:

   This version number MUST NOT be higher
   than that requested by the client.

Notes:

Capitalized "NOT" is needed per RFC 2119.

Errata ID: 5828
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.3.10 says:

   pgp-ascii-armor-start and the pgp-ascii-armor-end are built according
   to [RFC2440], Section 6.2., "Forming ASCII Armor".

It should say:

   pgp-ascii-armor-start and pgp-ascii-armor-end are built according
   to [RFC2440], Section 6.2, "Forming ASCII Armor".

Errata ID: 5829
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.3.10 says:

       Newsgroup-Type: Announce
       Date-Create: 19950725182040
       Name: humanities.classics
       [...]
       -----BEGIN PGP SIGNATURE-----
       Version: GnuPG v1.0.7 (IRIX64)

It should say:

       Newsgroup-Type: Announce
       Date-Create: 19950725182040

       Name: humanities.classics
       [...]
       -----BEGIN PGP SIGNATURE-----
       Version: GnuPG v1.0.7 (IRIX64)

Notes:

In the first example, an empty separation line is missing before the beginning of the description of another newsgroup.

Errata ID: 5830
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.4 says:

   Description: Name of a newsgroup

   Example:     Status: Hierarchy-Complete

   Example:     Status: Group-Moderated

   Comment:     The value can be used as default value for the
                "Followup-To:" header on postings to a moderated group.
                This value is only useful on groups that are moderated
                (Status Group-Moderated) and have a dedicated discussion
                group.

   Comment:     If there is no "Mod-Sub-Adr" for a moderated newsgroup,
                "Mod-Wildcard" of the hierarchy is used.  This is useful
                only for moderated groups (Status Group-Moderated).

   Comment:     If there is no code "Mod-Adm-Adr" for a moderated
                newsgroup, "Mod-Wildcard" of the hierarchy is used.
                This is useful only for moderated groups
                (Status Group-Moderated).

   Example:     Encoding text/plain

   Description: Name of the hierarchy that replaced a removed hierarchy
                if status is "Hierarchy-Obsolete" or will replace a
                hierarchy if the date of removal is in the future.

   Description: Name of the newsgroup or newsgroups that will replace a
                removed newsgroup if status is  "Group-Removed" or will
                replace the newsgroup if the date of removal is in the
                future.

It should say:

   Description: Name of a newsgroup.

   Example:     Status: Complete

   Example:     Status: Moderated

   Comment:     The value can be used as default value for the
                "Followup-To:" header field on postings to a moderated
                group.  This value is only useful on groups that are
                moderated (Status "Moderated") and have a dedicated
                discussion group.

   Comment:     If there is no "Mod-Sub-Adr" for a moderated newsgroup,
                "Mod-Wildcard" of the hierarchy is used.  This is useful
                only for moderated groups (Status "Moderated").

   Comment:     If there is no code "Mod-Adm-Adr" for a moderated
                newsgroup, "Mod-Wildcard" of the hierarchy is used.
                This is useful only for moderated groups
                (Status "Moderated").

   Example:     Encoding: text/plain

   Description: Name of the hierarchy that replaced a removed hierarchy
                if status is "Obsolete" or will replace a
                hierarchy if the date of removal is in the future.

   Description: Name of the newsgroup or newsgroups that will replace a
                removed newsgroup if status is "Removed" or will
                replace the newsgroup if the date of removal is in the
                future.

Notes:

Several fixes in syntax and also in spelling of keywords.

Errata ID: 5832
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Held for Document Update by: Adrian Farrel
Date Held: 2019-08-18

Section 6.3.4 says:

   Serial
[...]
   Used for:    newsgroup
   Mandatory:   no
   Inheritable: no
   Repeatable:  no

It should say:

   Serial
[...]
   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  no

Notes:

"Inheritable" does not apply to newsgroups.

Status: Rejected (2)

RFC 4707, "Netnews Administration System (NAS)", October 2006

Source of RFC: INDEPENDENT

Errata ID: 5814
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Rejected by: Adrian Farrel
Date Rejected: 2019-08-18

Throughout the document, when it says:


Notes:

The report raised said:

> A future revision of the NAS protocol should mention the character set that MUST
> be used in commands, and also in answers.
>
> I advise current NAS implementations to use UTF-8 everywhere because UTF-8 is the
> encoding that will be encouraged in Netnews (NNTP commands already are in UTF-8
> per RFC 3977, and internationalized headers including newsgroup names are likely to
> be in UTF-8).

Whether or not this is good advice to future specifications and current implementations, this is not an erratum. Changes of this nature require to be documented in separate publications.
--VERIFIER NOTES--

Errata ID: 5819
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Élie
Date Reported: 2019-08-18
Rejected by: Adrian Farrel
Date Rejected: 2019-08-18

Section 6.3.3.4 says:

   The VERS command is used to determine the protocol level to use
   between client and server.  The parameter is a protocol level that
   the client supports and wants to use.  The server will respond with
   the highest level accepted.
[...]
   When no option is given, the current protocol level will be printed.

It should say:

   The VERS command is used to determine the protocol level to use
   between client and server.  The optional parameter is a protocol
   level that the client supports and wants to use.  When this
   parameter is given, and is valid, the server will respond with
   the highest level accepted, at the start of the second line of its
   response, and the highest level it supports, at the end of that
   same line.
[...]
   When no parameter is given, or if the given parameter is invalid,
   the server will respond with the current protocol level, at the start
   of the second line of its response.

Notes:

The description should detail the syntax of the different possible answers to the VERS command. Especially, ABNF shows two "level" keywords in 302 and 402 answers, that are not explained in the original text.
--VERIFIER NOTES--
The suggested replacement text adds little or nothing to the understanding of the text which was clear to this uninformed reader.

Report New Errata