Errata for RFC 5536 and 5537

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

Hi,

According to previous discussion on the mailing-list, I reckon that
the statuses of current open errata for RFCs 5536 and 5537 are:

1979 -> still no validation, though I believe it should be VERIFIED.
        Can someone confirm?

1980 -> it should be reworded as follows, and VERIFIED.

1981 -> it should be VERIFIED.

1982 -> I don't know; the original text is right and reads better.
        Should it be VERIFIED or REJECTED?  (with a note added to
        say that both forms are correct English)

1983 -> it should be VERIFIED.

1993 -> it should be VERIFIED.


-- 
Julien


-----------------------------------------------------------------------
RFC 5537 - Erratum 1980
-----------------------------------------------------------------------

It should be VERIFIED.

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):


Original Text
-------------
(a)  Section 3.1, last paragraph:

|       ... trace headers ...

(b)  Section 3.4, fourth paragraph:

|       ... an Injection-Date header.

(c)  Section 3.4.4, second paragraph:

|       ... a References header, ...

(d)  Section 3.5, numbered processing steps:
   
    4.  [...]
                                           ... in the Newsgroups
|       header is valid.

    [...]

    6.  [...]
                                                               [...]  It
        MAY add other header fields not already provided by the poster,
        but injecting agents are encouraged to use the Injection-Info
|       header for such information and to minimize the addition of
|       other headers.  [...]
   
|   7.  If the Newsgroups header contains one or more moderated groups
        and the proto-article does not contain an Approved header field,
        the injecting agent MUST either forward it to a moderator as
        specified in Section 3.5.1 or, if that is not possible, reject
        it.  This forwarding MUST be done after adding the Message-ID
|       and Date headers if required, and before adding the Injection-
|       Info and Injection-Date headers.
         
(e)  Section 3.6, first paragraph

|       ... forgery of Path and Injection-Info headers, ...
 
(f)  Section 5.2.1, first paragraph:

   The newgroup control message requests that the specified group be
   created or, if already existing, that its moderation status or
|  description be changed.  The syntax of its Control header field is:
         
         control-command     =/ Newgroup-command
         Newgroup-command    = "newgroup" Newgroup-arguments
         [...]

(g)  Section 5.2.2, first paragraph:

   The rmgroup control message requests that the specified group be
   removed from a news server's list of valid groups.  The syntax of its
|  Control header field is:

(h)  Section 5.2.3, first paragraph:

                                                 [...]  The syntax of
|  its Control header field is:

(i)  Section 5.2.3, last paragraph:

   The body of the message is an entity of type application/
   news-checkgroups.  It SHOULD be declared as such with appropriate
|  MIME headers, but news servers SHOULD interpret checkgroups messages
|  that lack the appropriate MIME headers as if the body were of type
   application/news-checkgroups for backward compatibility.

(j)  Section 5.3, first paragraph:

   The cancel control message requests that a target article be
   withdrawn from circulation and access.  The syntax of its Control
|  header field is:

(k)  Section 5.5, second paragraph:

   ihave and sendme control messages share similar syntax for their
|  Control header fields and bodies:

(l)  Appendix A, first bullet:

                                              [...]  Folding of the
|     Path header is permitted.





Corrected Text
--------------
(a)  Section 3.1, last paragraph:

|       ... trace header fields ...

(b)  Section 3.4, fourth paragraph:

|       ... an Injection-Date header field.

(c)  Section 3.4.4, second paragraph:

|       ... a References header field, ...

(d)  Section 3.5, numbered processing steps:

    4.  [...]
                                           ... in the Newsgroups
|       header field is valid.

    [...]

    6.  [...]
                                                               [...]  It
        MAY add other header fields not already provided by the poster,
        but injecting agents are encouraged to use the Injection-Info
|       header field for such information and to minimize the addition 
|       of other header fields.  [...]
   
|  7.   If the Newsgroups header field contains one or more moderated
        groups and the proto-article does not contain an Approved header
        field, the injecting agent MUST either forward it to a moderator
        as specified in Section 3.5.1 or, if that is not possible,
        reject it.  This forwarding MUST be done after adding the
|       Message-ID and Date header fields if required, and before adding
|       the Injection-Info and Injection-Date header fields.

(e)  Section 3.6, first paragraph

|       ... forgery of Path and Injection-Info header fields, ...

(f)  Section 5.2.1, first paragraph:

   The newgroup control message requests that the specified group be
   created or, if already existing, that its moderation status or
|  description be changed.  The syntax of its Control header field
|  body is:
         
         control-command     =/ Newgroup-command
         Newgroup-command    = "newgroup" Newgroup-arguments
         [...]

(g)  Section 5.2.2, first paragraph:

   The rmgroup control message requests that the specified group be
   removed from a news server's list of valid groups.  The syntax of its
|  Control header field body is:

(h)  Section 5.2.3, first paragraph:

                                                 [...]  The syntax of
|  its Control header field value is:

(i)  Section 5.2.3, last paragraph:

   The body of the message is an entity of type application/
   news-checkgroups.  It SHOULD be declared as such with appropriate
|  MIME header fields, but news servers SHOULD interpret checkgroups
|  messages that lack the appropriate MIME header fields as if the body
   were of type application/news-checkgroups for backward compatibility.

(j)  Section 5.3, first paragraph:

   The cancel control message requests that a target article be
   withdrawn from circulation and access.  The syntax of its Control
|  header field body is:

(k)  Section 5.5, second paragraph:

   ihave and sendme control messages share similar syntax for their
|  Control header field bodies and message bodies:

(l)  Appendix A, first bullet:

                                              [...]  Folding of the
|     Path header field is permitted.


Notes
-----
Rationale:
Contrary to its companion document, RFC 5536, this RFC mixes precise
IETF terminology for protocol elements and colloquial abuse of it in
various places.  For clarity and consistency, it should also
inequivocally make use of the standard terminology; the fields
of the "header" that a protocol layer or sub-layer adds to its
payload are "header fields", not "headers" in itself.
Similarly, denoting as "header field" a "header field body" is
confusing -- items (f), (g), (h), (j), and (k) above.