RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search