Subject: [Technical Errata Reported] RFC7230 (4169)

From: RFC Errata System <[email-masked]>
Date: Sun, 9 Nov 2014 16:20:51 -0800 (PST)

The following errata report has been submitted for RFC7230,
"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".

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

--------------------------------------
Type: Technical
Reported by: Simon Schueppel <[email-masked]>

Section: 7

Original Text
-------------
     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]

     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

   Empty elements do not contribute to the count of elements present.
   For example, given these ABNF productions:

     example-list      = 1#example-list-elmt
     example-list-elmt = token ; see Section 3.2.6

   Then the following are valid values for example-list (not including
   the double quotes, which are present for delimitation only):

     "foo,bar"
     "foo ,bar,"
     "foo , ,bar,charlie   "

Corrected Text
--------------
     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]

     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

   Empty elements do not contribute to the count of elements present.
   For example, given these ABNF productions:

     example-list      = 1#example-list-elmt
     example-list-elmt = token ; see Section 3.2.6

   Then the following are valid values for example-list (not including
   the double quotes, which are present for delimitation only):

     "foo,bar"
     "foo ,bar,"
     "foo , ,bar,charlie"

Notes
-----
"foo , ,bar,charlie   " cannot be derived from 1#token (legacy list rule)
"foo , ,bar,charlie" can be derived from 1#token (legacy list rule)

Instructions:
-------------
This erratum 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. 

--------------------------------------
RFC7230 (draft-ietf-httpbis-p1-messaging-26)
--------------------------------------
Title               : Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Publication Date    : June 2014
Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Nov 2014 00:59:43 -0500

This seems to be a correct report: the grammar supports OWS before or
after a comma, but not before the first element or after the last.

Julian?

Barry

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Nov 2014 10:02:47 +0100

> after a comma, but not before the first element or after the last.

Sounds right to me, but I'd like to double-check with Roy :-)

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 10 Nov 2014 22:48:37 +1300

On 10/11/2014 10:02 p.m., Julian Reschke wrote:
>> This seems to be a correct report: the grammar supports OWS
>> before or after a comma, but not before the first element or
>> after the last.
>> 
>> Julian?
>> 
>> Barry
> 

By my reading the OWS prefix and trailer in lists are a property of
the header-field definition in section 3.2. Not part of the #rule
element itself.

Amos

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Nov 2014 15:18:52 -0500

> the header-field definition in section 3.2. Not part of the #rule

Quite correct, Amos; thanks for that.  That leads me to think that
this is "Reject".  I'd still like to hear from Roy.

Barry

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 10 Nov 2014 10:40:19 -1000

> this is "Reject".  I'd still like to hear from Roy.

That would be true if the example was a header field, but it isn't.
It is only talking about the field-value of the production, which already
excludes the trailing whitespace of header-fields.

So, the Errata is valid and the last example should not have trailing
space at the end of the value.

....Roy

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Nov 2014 18:03:34 -0500

> space at the end of the value.

...which is why we wanted to wait for your comments.  I'm off to mark
this "Verified" now.

Barry

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Nov 2014 16:24:43 -0800

Roy suggests that the example is in error. Is this really a technical
erratum then?

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Nov 2014 14:30:24 -1000

> Roy suggests that the example is in error. Is this really a technical

I thought about that, but decided that the error could mislead someone
into producing or accepting the trailing blanks, so I left it as
"technical".

b

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 10 Nov 2014 14:46:30 -1000

> into producing or accepting the trailing blanks, so I left it as

That's actually not a problem, since it would just be treated as the
trailing whitespace in the header field ABNF.

This doesn't really fit either errata type.  What the database needs is
a separate "error in example" type.

....Roy