Subject: Errata for RFC 5536 and 5537

From: Julien ÉLIE <[email-masked]>
Date: Fri, 15 Jan 2010 23:55:44 +0100

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.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 19 Jan 2010 12:35:03 -0800

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 <[email-masked]> wrote:
> |       header field for such information and to minimize the addition |
>   of other header fields.  [...]

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 19 Jan 2010 22:10:35 +0100

Hi Lisa,

> corrections looking for technical errata.

OK, thanks!

> 1980 -> it should be reworded as follows, and VERIFIED.

http://www.rfc-editor.org/errata_search.php?eid=1980

The correction is inconsistent and wrong.

I do not understand why we have:

---------------------------------------------------
Throughout the document, when it says:

|        ... trace headers ...

(b)  Section 3.4.4, second paragraph:

(c)  Section 3.5, numbered processing steps:
---------------------------------------------------
It should say:

(b)  Section 3.4.4, second paragraph:

(c)  Section 3.5, numbered processing steps:

Julian Elie suggests the corrected text:

Corrected Text
--------------

(c)  Section 3.4.4, second paragraph:
---------------------------------------------------

It does not match the letters (a), (b), (c), etc.

I thought that the new original text I suggested was to be put
instead of the previous original text.  And my corrected text
instead of the previous corrected text.  And also my suggestion
of note.  Otherwise, everything is inconsistent.

Besides, the original text contains a typo:

g)  Section 5.2.3, first paragraph:
(
                                                 [...]  The syntax of
|  its Control header field is:

And all my corrected text is badly formatted.  It was not what
I suggested at all!
Missing leading spaces, (d) totally wrong...

Could you please fix it?

Thanks beforehand,

-- 
Julien ÉLIE

« Ex nihilo nihil. » (Perse)

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 19 Jan 2010 14:22:30 -0800

Hi Julien,

I appended your re-correction of the corrected text, rather than
replace, since you were not the reporter, introduced by "Julian Elie
suggests the corrected text: ".  Since the errata is held for document
update, the authors of the next version of the document can analyse
all the suggestions and can surely correct for formatting.

Lisa

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 20 Jan 2010 00:04:27 +0100

Hi Lisa,

> all the suggestions and can surely correct for formatting.

Buy is it a reason for not having errata of quality?

Well, if it is what you want, I can do nothing more.
I'm not going to argue more on that subject on which I have already
spent far too much time.

I will only say that:
 * the erratum mentions that I "suggest the corrected text", which is wrong
   because it is not my suggestion (the formatting I provided was better);
 * the erratum is inconsistent;
 * the process is inconsistent (no append for erratum 1787 for instance);
 * my first name has been mispelled in the edited text:  it is Julien,
   and not Julian.

But well, after all, I don't mind.  I just wanted to give some help
and review to have proper errata on rfc-editor.org but it appears that
it is not what people expect from rfc-editor.org; so be it that way.

I thought that people reading errata would be more pleased to have
detailed, complete information of good quality about an erratum.

Anyway, thanks for your work on RFCs and errata.  I know you are also
writing RFCs (I already read your PATCH method and your guidance about
draft standards).  That's great work, and it requires time and energy.
I also understand that editing errata can be exhausting and is not
quite fun.

All the best for the future,

-- 
Julien ÉLIE