RFC Errata
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.