Subject: [Editorial Errata Reported] RFC5537 (1980)

From: RFC Errata System <[email-masked]>
Date: Mon, 28 Dec 2009 04:59:22 -0800 (PST)

The following errata report has been submitted for RFC5537,
"Netnews Architecture and Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5537&eid=1980

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[email-masked]>

Section: GLOBAL

Original Text
-------------
(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.

Corrected Text
--------------
(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.

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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5537 (draft-ietf-usefor-usepro-14)
--------------------------------------
Title               : Netnews Architecture and Protocols
Publication Date    : November 2009
Author(s)           : R. Allbery, Ed., C. Lindsey
Category            : PROPOSED STANDARD
Source              : Usenet Article Standard Update
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Russ Allbery <[email-masked]>
Date: Mon, 28 Dec 2009 11:39:13 -0800

>   payload are "header fields", not "headers" in itself.

Argh, I thought I caught all of these.  I'm sorry about that.  The
corrections (a), (b), (c), (d), (h), and (k) are correct.

>   confusing -- items (e), (f), (g), (i), and (j) above.

I don't understand the rationale for this change.  I believe the current
text for those items is already correct and this change should not be
necessary.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 28 Dec 2009 21:24:25 +0100 (MEZ)

> text for those items is already correct and this change should not be

Russ,
thanks for your very quick responses.

The Control syntax seems to be the single issue that needs elaboration.
(I did not want to add too much stuff to the Errata note.)

Quoting from RFC 5536, Section 3.2.3, on top of page 18:

   control         =  "Control:" SP *WSP control-command *WSP CRLF

   control-command =  verb *( 1*WSP argument )
   verb            =  token
   argument        =  1*( %x21-7E )

These are the syntax rules for the entire header field, giving
the header field name, "Control", the separating colon ":",
and the general syntax of the header field value, essentially
<control-command> plus enclosing optional whitespace.

RFC 5537 imports the <control-command> rule (cf. Section 1.4,
on page 4) and states in the second paragraph of Section 5
(please note the "of" in the first line here!):

   The <control-command> of a Control header field comprises a <verb>,
   which indicates the action to be taken, and one or more <argument>
   values, which supply the details.  For some control messages, the
   body of the article is also significant.  Each recognized <verb> (the
   control message type) is described in a separate section below. [...]

Hence, for instance for (e), the ABNF in Section 5.2.1 of RFC 5537,

        control-command     =/ Newgroup-command
        Newgroup-command    = "newgroup" Newgroup-arguments
        Newgroup-arguments  = 1*WSP newsgroup-name
                              [ 1*WSP newgroup-flag ]
        newgroup-flag       = "moderated"

augments the syntax rule for the Control header field *value*.

The syntax of the entire Control header field is still given
by the <control> ABNF production from RFC 5536 (quoted above).
However, taking the RFC prose text literally,

             ...   The syntax of its Control header field is:
        control-command     =/ Newgroup-command
        ...
would pretend to indicate that the "Control:" part were dropped here!

That's why the Errata note adjusts the text to say:
                                                         vvvvvvv
|            ...   The syntax of its Control header field value is:
        control-command     =/ Newgroup-command
        ...

Does that suffice for clarification?

The iterated instances in 5.2.2, 5.2.3, 5.3, and 5.5 are analogous.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Russ Allbery <[email-masked]>
Date: Mon, 28 Dec 2009 12:33:21 -0800

> These are the syntax rules for the entire header field, giving the
> header field name, "Control", the separating colon ":", and the general
> syntax of the header field value, essentially <control-command> plus
> enclosing optional whitespace.

[...]

> The syntax of the entire Control header field is still given by the
> <control> ABNF production from RFC 5536 (quoted above).  However, taking
> the RFC prose text literally,

> would pretend to indicate that the "Control:" part were dropped here!

Oh!  I understand now.

Given this, I agree with all the changes you propose and think the errata
should be verified in its entirety.

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 28 Dec 2009 19:47:57 +0100

Hi Alfred,

I have two major remarks:

1/ If your report is verified, there is also Section 3.4, fourth paragraph,
to amend:

    predating this specification do not add an Injection-Date header.

"field" is missing.

>  confusing -- items (e), (f), (g), (i), and (j) above.

Where do you draw the "header field value" terminology?
Isn't it "header field body"?  RFCs 5322 and 5536 define
"header field body" but not "header field value".

And also a few other points:

Note that when for instance we have in Section 6.1 of RFC 5537:

   To best ensure that it will be relayed to the same news servers as
   the original message, a cancel control message SHOULD have the same
   Newsgroups header field as the message it is cancelling.

or in 6.1:

   Cancel control messages are not required to have the same Newsgroups
   header field as the messages they are cancelling.  Since they are
   sometimes processed before the original message is received, it may
   not be possible to check that the Newsgroup header fields match.

of course it is not exactly the same header field because
   Newsgroups: group1,group2
and
   Newsgroups:    groups1,group2
are equivalent...  WSP and FWS should not be taken into account...

Should such terminology also be fixed?

And in Section 5.5:

   Contrary to [RFC1036], the relayer-name MUST be given as the last
   argument in the Control header field.

Wouldn't it be better to say it is the header body?

>  payload are "header fields", not "headers" in itself.

Shouldn't RFC 3977 also be checked for that?

   The distrib.pats list is maintained by some NNTP servers to assist
   clients to choose a value for the content of the Distribution header
   of a news article being posted.

   Lines or Bytes header

and other similar terminology.  RFC 3977 defines headers this way:

   The headers of an article consist of one or more header lines.  Each
   header line consists of a header name, a colon, a space, the header
   content, and a CRLF, in that order.

-- 
Julien ÉLIE

« Ne parlez jamais de vous, ni en bien, car on ne vous
  croirait pas, ni en mal car on ne vous croirait que trop. » (Confucius)

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 28 Dec 2009 21:42:38 +0100

Hi Russ,

Maybe I should re-ask, before the verification takes place...
Didn't the mails I sent for errata 1979, 1980 and 1982 reach you?

> should be verified in its entirety.

If the erratum is to be verified, be sure to also include the fourth paragraph
of Section 3.4.  It should also be amended:

"field" is missing.

Another thing:  why is it "header field value" and not "header field body"?
RFCs 5322 and 5536 define "header field body" but not "header field value".
Where is the terminology drawn?

-- 
Julien ÉLIE

« Plus un ordinateur possède de RAM, plus vite il peut générer
  un message d'erreur. »

---

From: Russ Allbery <[email-masked]>
Date: Tue, 29 Dec 2009 10:19:20 -0800

> Didn't the mails I sent for errata 1979, 1980 and 1982 reach you?

They did, yes.

>> Given this, I agree with all the changes you propose and think the
>> errata should be verified in its entirety.

> "field" is missing.

I agree with this change.  I'm not sure how this process works -- whether
it's better to amend the existing errata or add another one.

> Another thing:  why is it "header field value" and not "header field
> body"?  RFCs 5322 and 5536 define "header field body" but not "header
> field value".  Where is the terminology drawn?

This is a good point that I didn't check originally.  It does sound like
header field body might be a better term to use.

---

From: RFC Editor <[email-masked]>
Date: Tue, 29 Dec 2009 10:47:05 -0800

Russ,

In our opinion, it's better to ammend the existing errata report.  The
errata system was not meant to hold errata for errata entries or to
hold multpile errata entries for the same error, as it could be
confusing for readers.

Please note that the responsible AD has the ability to edit the entry
before verifying it. 

Please let us know if you have any questions.

Thank you.

RFC Editor/sg

On Tue, Dec 29, 2009 at 10:19:20AM -0800, Russ Allbery wrote:
> Julien ?LIE <[email-masked]> writes:
>