RFC Errata
Found 6 records.
Status: Verified (2)
RFC 5537, "Netnews Architecture and Protocols", November 2009
Note: This RFC has been updated by RFC 8315
Source of RFC: usefor (app)
Errata ID: 1981
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Verifier Name: Lisa Dusseault
Date Verified: 2010-01-19
Section 3.2.1 says:
... first paragraph:
If a relaying or serving agent receives an article from an injecting
| or serving agent that is part of the same news server, it MAY leave
^^^^^^^
the Path header field of the article unchanged. [...]
It should say:
If a relaying or serving agent receives an article from an injecting
| or relaying agent that is part of the same news server, it MAY leave
^^^^^^^^
the Path header field of the article unchanged. [...]
Notes:
Rationale:
Cf. the definition of agent roles presented in Section 1 and the
first paragraph of Section 3:
Serving agents only forward to reading agents, and in that step,
the articles are not modified in any way.
Errata ID: 1993
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2009-12-28
Verifier Name: Lisa Dusseault
Date Verified: 2010-01-19
Section 5.2.1.1 says:
A newgroup control message requesting creation of the moderated
newsgroup example.admin.info.
From: "example.* Administrator" <admin@noc.example>
Newsgroups: example.admin.info
Date: 27 Feb 2002 12:50:22 +0200
Subject: cmsg newgroup example.admin.info moderated
Approved: admin@noc.example
Control: newgroup example.admin.info moderated
Message-ID: <ng-example.admin.info-20020227@noc.example>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nxtprt"
Content-Transfer-Encoding: 8bit
It should say:
A newgroup control message requesting creation of the moderated
newsgroup example.admin.info.
| Path: not-for-mail
From: "example.* Administrator" <admin@noc.example>
Newsgroups: example.admin.info
Date: 27 Feb 2002 12:50:22 +0200
Subject: cmsg newgroup example.admin.info moderated
Approved: admin@noc.example
Control: newgroup example.admin.info moderated
Message-ID: <ng-example.admin.info-20020227@noc.example>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nxtprt"
Content-Transfer-Encoding: 8bit
Notes:
As the mandatory Path: header field is missing, this control message is only a proto-article.
A control message is defined in Section 5 as an article which contains a Control: header field. Therefore, a Path: header field should be added to the headers of this sample newgroup control article.
Status: Reported (1)
RFC 5537, "Netnews Architecture and Protocols", November 2009
Note: This RFC has been updated by RFC 8315
Source of RFC: usefor (app)
Errata ID: 4468
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2015-09-08
Section 3.5 says:
An injecting agent processes proto-articles as follows:
[...]
2. It MUST reject any proto-article that does not have the proper
mandatory header fields for a proto-article, that has Injection-
Info or Xref header fields, that has a Path header field
containing the "POSTED" <diag-keyword>, or that is not
syntactically valid as defined by [RFC5536].
It should say:
An injecting agent processes proto-articles as follows:
[...]
2. It MAY modify header fields so that the proto-article conforms
to [RFC5536]. If made, such modifications SHOULD be as
minimal as possible. The usual changes are the removal of
empty header fields and a bit of cleaning in folding or the
syntax used.
3. It MUST reject any proto-article that does not have the proper
mandatory header fields for a proto-article, that has Injection-
Info or Xref header fields, that has a Path header field
containing the "POSTED" <diag-keyword>, or that is not
syntactically valid as defined by [RFC5536].
Notes:
Subsequent items should be renumbered at the same time.
Rationale: most of server software has been removing empty header fields and made syntax cleaning for ages. Some news clients do rely on that "feature" of removing empty header fields, i.e by putting empty Followup-To, Summary and Keywords header fields into each article opened in the editor and not removing them if empty when posting the article.
Though RFC 1849 (Son-of-1036) says the posting agent SHOULD delete empty headers, in practice the relayer (injecting agent) took care of that when not done by the posting agent.
This erratum describes a variation from the standard and could be taken into account in a revision of RFC 5537, if it happens.
Status: Held for Document Update (3)
RFC 5537, "Netnews Architecture and Protocols", November 2009
Note: This RFC has been updated by RFC 8315
Source of RFC: usefor (app)
Errata ID: 1983
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Lisa Dusseault
Throughout the document, when it says:
(a) Section 3.10, first paragraph:
A gateway transforms an article into the native message format of
another medium, or translates the messages of another medium into
news articles, or transforms articles into proto-articles for
injection into a separate Netnews network. Encapsulation of a news
| article into a message of MIME type application/news-transmission, or
the subsequent undoing of that encapsulation, is not gatewaying since
it involves no transformation of the article.
(b) Section 4 (page 29):
| The updated MIME media type definition of message/news is:
| MIME type name: message
| MIME subtype name: news
Required parameters: ...
(c) Section 4.1 (bottom of page 30):
| The MIME media type definition of application/news-transmission is:
| MIME type name: application
| MIME subtype name: news-transmission
Required parameters: ...
(d) Section 4.2 (bottom of page 31 plus top of page 32):
| The MIME media type definition of application/news-groupinfo is:
| MIME type name: application
| MIME subtype name: news-groupinfo
Required parameters: none
Optional parameters: charset, which MUST be a charset
| registered for use with MIME text types.
It has the same syntax as the parameter
defined for text/plain [RFC2046]. [...]
(e) Section 4.3 (page 33):
| The MIME media type definition of application/news-checkgroups is:
| MIME type name: application
| MIME subtype name: news-checkgroups
Required parameters: none
Optional parameters: charset, which MUST be a charset
| registered for use with MIME text types.
It has the same syntax as the parameter
defined for text/plain [RFC2046].
It should say:
(a) Section 3.10, first paragraph:
A gateway transforms an article into the native message format of
another medium, or translates the messages of another medium into
news articles, or transforms articles into proto-articles for
injection into a separate Netnews network. Encapsulation of a news
| article into a message of media type application/news-transmission,
or the subsequent undoing of that encapsulation, is not gatewaying
since it involves no transformation of the article.
(b) Section 4 (page 29):
| The updated media type definition of message/news is:
| Type name: message
| Subtype name: news
Required parameters: ...
(c) Section 4.1 (bottom of page 30):
| The media type definition of application/news-transmission is:
| Type name: application
| Subtype name: news-transmission
Required parameters: ...
(d) Section 4.2 (bottom of page 31 plus top of page 32):
| The media type definition of application/news-groupinfo is:
| Type name: application
| Subtype name: news-groupinfo
Required parameters: none
Optional parameters: charset, which MUST be a charset
| registered for use with 'text' media
types.
It has the same syntax as the parameter
defined for text/plain [RFC2046]. [...]
(e) Section 4.3 (page 33):
| The media type definition of application/news-checkgroups is:
| Type name: application
| Subtype name: news-checkgroups
Required parameters: none
Optional parameters: charset, which MUST be a charset
| registered for use with 'text' media
types.
It has the same syntax as the parameter
defined for text/plain [RFC2046].
Notes:
Rationale:
RFC 5537 does not follow the IETF standard terminology reinforced
by RFC 4288 and does not properly use the media type registration
template from Section 10 of RFC 4288.
RFC 4288 clarifies that IETF media types (and subtypes) have
outgrown the Internet Email MIME environment and now are used
in non-email environments as well; for instance in the context
of Netnews (this RFC!). Therefore, all mention of "MIME" in the
context of Internet media types must be avoided. See Sections 1
through 3 of RFC 4288 for more rationale and Section 10 there for
the registration template to be used since RFC 4288, in 2005.
Editorial Note (keep for update):
The structure of Section 4 would perhaps more reasonably have been
split into a single-paragraph Section 4 and packing the remainder
of 4. into a new subsection 4.1, "Obsolescence of message/news",
with the remaining subsection numbers 4.* bumped accordingly.
Errata ID: 1980
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Lisa Dusseault
Date Held: 2010-01-19
Throughout the document, when it says:
(a) Section 3.1, last paragraph:
| ... trace headers ...
(b) Section 3.4.4, second paragraph:
| ... a References header, ...
(c) 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.
(d) Section 3.6, first paragraph
| ... forgery of Path and Injection-Info headers, ...
(e) 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
[...]
(f) 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:
g) Section 5.2.3, first paragraph:
(
[...] The syntax of
| its Control header field is:
(h) 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.
(i) 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:
(j) Section 5.5, second paragraph:
ihave and sendme control messages share similar syntax for their
| Control header fields and bodies:
(k) Appendix A, first bullet:
[...] Folding of the
| Path header is permitted.
It should say:
(a) Section 3.1, last paragraph:
| ... trace header fields ...
(b) Section 3.4.4, second paragraph:
| ... a References header field, ...
(c) 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.
(d) Section 3.6, first paragraph
| ... forgery of Path and Injection-Info header fields, ...
(e) 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
| value is:
control-command =/ Newgroup-command
Newgroup-command = "newgroup" Newgroup-arguments
[...]
(f) 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 value is:
(g) Section 5.2.3, first paragraph:
[...] The syntax of
| its Control header field value is:
(h) 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.
(i) 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 value is:
(j) Section 5.5, second paragraph:
ihave and sendme control messages share similar syntax for their
| Control header field values and message bodies:
(k) Appendix A, first bullet:
[...] Folding of the
| Path header field is permitted.
Julian Elie suggests the corrected text:
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 value" is
confusing -- items (e), (f), (g), (i), and (j) above.
Errata ID: 1982
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Lisa Dusseault
Section 3.4.2, NOTE says:
... unintended repeat injection into the same network, ...
^
It should say:
... unintended repeated injection into the same network, ...
^^^