Subject: [Editorial Errata Reported] RFC7540 (4647)

From: RFC Errata System <[email-masked]>
Date: Tue, 29 Mar 2016 01:19:58 -0700 (PDT)

The following errata report has been submitted for RFC7540,
"Hypertext Transfer Protocol Version 2 (HTTP/2)".

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

--------------------------------------
Type: Editorial
Reported by: Jessie Liu <[email-masked]>

Section: Global

Original Text
-------------
 open:
      A stream in the "open" state may be used by both peers to send
      frames of any type.  In this state, sending peers observe
      advertised stream-level flow-control limits (Section 5.2).

-----------------------------------

   The entries in the following table are registered by this document.

   +---------------+------+--------------+
   | Frame Type    | Code | Section      |
   +---------------+------+--------------+
   | DATA          | 0x0  | Section 6.1  |
   | HEADERS       | 0x1  | Section 6.2  |
   | PRIORITY      | 0x2  | Section 6.3  |
   | RST_STREAM    | 0x3  | Section 6.4  |
   | SETTINGS      | 0x4  | Section 6.5  |
   | PUSH_PROMISE  | 0x5  | Section 6.6  |
   | PING          | 0x6  | Section 6.7  |
   | GOAWAY        | 0x7  | Section 6.8  |
   | WINDOW_UPDATE | 0x8  | Section 6.9  |
   | CONTINUATION  | 0x9  | Section 6.10 |
   +---------------+------+--------------+

Corrected Text
--------------
 open:
      A stream in the "open" state MAY be used by both peers to send
      frames of any type.  In this state, sending peers observe
      advertised stream-level flow-control limits (Section 5.2).

-----------------------------------

   The entries in the following table are registered by this document.

   +---------------+------+----------------+
   | Frame Type    | Code | Specification |
   +---------------+------+----------------+
   | DATA          | 0x0  | Section 6.1  |
   | HEADERS       | 0x1  | Section 6.2  |
   | PRIORITY      | 0x2  | Section 6.3  |
   | RST_STREAM    | 0x3  | Section 6.4  |
   | SETTINGS      | 0x4  | Section 6.5  |
   | PUSH_PROMISE  | 0x5  | Section 6.6  |
   | PING          | 0x6  | Section 6.7  |
   | GOAWAY        | 0x7  | Section 6.8  |
   | WINDOW_UPDATE | 0x8  | Section 6.9  |
   | CONTINUATION  | 0x9  | Section 6.10 |
   +---------------+------+--------------+

Notes
-----
2 editorial issues in section 5.1 and section 11.2.

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. 

--------------------------------------
RFC7540 (draft-ietf-httpbis-http2-17)
--------------------------------------
Title               : Hypertext Transfer Protocol Version 2 (HTTP/2)
Publication Date    : May 2015
Author(s)           : M. Belshe, R. Peon, M. Thomson, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Mar 2016 19:33:15 +1100

> 2 editorial issues in section 5.1 and section 11.2.

Valid.  Though neither demand a change.  Lowercase "may" is
acceptable, though perhaps a poor choice of word in context.  And
s/Section/Specification aligns better with the registration template,
but worse with the document itself.

We should mark this "Hold for document update"

---

From: Barry Leiba <[email-masked]>
Date: Tue, 29 Mar 2016 10:21:26 -0400

> but worse with the document itself.

Actually, I'm going to disagree with the first: I think this is
absolutely not a 2119 "MAY".  The definition of "open" isn't
presenting a protocol option.  It's stating a fact, that this is what
open streams are used for.

> We should mark this "Hold for document update"

Apart from the above, it's not generally a good idea to submit one
errata report for multiple distinct errata.  I ask the submitter to
please re-submit these as two separate reports, declaring the relevant
section in each (not "global").  And I ask the RFC Editor to remove
this report in anticipation of that.

The submitter should also consider that I will mark the "MAY" portion
of the report as "Rejected".  I agree that HFDU is a suitable
disposition for the table heading.

Barry