headers
RFC Errata System | 28 Dec 2009 13:59
Favicon

[Editorial Errata Reported] RFC5537 (1980)


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 <ah <at> TR-Sys.de>

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.
(Continue reading)

Permalink | Reply |
headers
Russ Allbery | 28 Dec 2009 20:39
Picon
Favicon
Gravatar

Re: [Editorial Errata Reported] RFC5537 (1980)


RFC Errata System <rfc-editor <at> rfc-editor.org> writes:

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

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

>   Similarly, denoting as "header field" a "header field value" is
>   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 (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply |
headers
Alfred Hönes | 28 Dec 2009 21:24
Picon

Re: [Editorial Errata Reported] RFC5537 (1980)


> RFC Errata System <rfc-editor <at> rfc-editor.org> writes:
>
>> 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.
>
> Argh, I thought I caught all of these.  I'm sorry about that.  The
> corrections (a), (b), (c), (d), (h), and (k) are correct.
>
>>   Similarly, denoting as "header field" a "header field value" is
>>   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 (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

Russ,
thanks for your very quick responses.

The Control syntax seems to be the single issue that needs elaboration.
(Continue reading)

Permalink | Reply |
headers
Russ Allbery | 28 Dec 2009 21:33
Picon
Favicon
Gravatar

Re: [Editorial Errata Reported] RFC5537 (1980)


Alfred Hönes <ah <at> TR-Sys.de> writes:

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

[...]

> 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
(Continue reading)

Permalink | Reply |
headers
Julien ÉLIE | 28 Dec 2009 21:42
Favicon

Re: [Editorial Errata Reported] RFC5537 (1980)


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?

> Given this, I agree with all the changes you propose and think the errata
> 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:

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

"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. »
Permalink | Reply |
headers
Russ Allbery | 29 Dec 2009 19:19
Picon
Favicon
Gravatar

Re: [Editorial Errata Reported] RFC5537 (1980)


Julien ÉLIE <julien <at> trigofacile.com> writes:

> Maybe I should re-ask, before the verification takes place...
> 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.

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

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

> "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.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
(Continue reading)

Permalink | Reply |
headers
RFC Editor | 29 Dec 2009 19:47
Favicon

Re: [Editorial Errata Reported] RFC5537 (1980)


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 <julien <at> trigofacile.com> writes:
> 
> > Maybe I should re-ask, before the verification takes place...
> > 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.
> 
> > If the erratum is to be verified, be sure to also include the fourth paragraph
> > of Section 3.4.  It should also be amended:
(Continue reading)

Permalink | Reply |
headers
Julien ÉLIE | 28 Dec 2009 19:47
Favicon

Re: [Editorial Errata Reported] RFC5537 (1980)


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.

2/ When you say:
>  Similarly, denoting as "header field" a "header field value" is
>  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:
(Continue reading)

Permalink | Reply |

Gmane