[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Errata for RFC 5536 and 5537
Done. The editorial ones I marked "hold for document update" because
the terminology issues won't affect an implementation's correctness,
and I do not like making implementers wade through terminology
corrections looking for technical errata.
Thanks,
Lisa
On Fri, Jan 15, 2010 at 2:55 PM, Julien ÉLIE <julien@xxxxxxxxxxxxxxx> wrote:
> 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.
>
>