- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Sun, 25 Mar 2018 00:48:38 +0000
- To: rfc-editor@rfc-editor.org
- Cc: fielding@gbiv.com, julian.reschke@greenbytes.de, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, Mark Nottingham <mnot@mnot.net>, pmcmanus@mozilla.com, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANh-dXmGDtrKWjShrJ4CR7AsQAcT3Fe0zOJ4DsBUwNpLfSg2EA@mail.gmail.com>
It probably makes sense to handle this during the HTTPtre process. I filed
an erratum to be sure not to forget it between now and when that repository
is created.
Jeffrey
On Sat, Mar 24, 2018 at 7:01 PM RFC Errata System <rfc-editor@rfc-editor.org>
wrote:
> The following errata report has been submitted for RFC7231,
> "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5300
>
> --------------------------------------
> Type: Technical
> Reported by: Jeffrey Yasskin <jyasskin@google.com>
>
> Section: 8.1
>
> Original Text
> -------------
> 8.1.1. Procedure
>
> HTTP method registrations MUST include the following fields:
>
> o Method Name (see Section 4)
>
> o Safe ("yes" or "no", see Section 4.2.1)
>
> o Idempotent ("yes" or "no", see Section 4.2.2)
>
> o Pointer to specification text
>
> Values to be added to this namespace require IETF Review (see
> [RFC5226], Section 4.1).
>
> …
>
> 8.1.3. Registrations
>
> The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
> populated with the registrations below:
>
> +---------+------+------------+---------------+
> | Method | Safe | Idempotent | Reference |
> +---------+------+------------+---------------+
> | CONNECT | no | no | Section 4.3.6 |
> | DELETE | no | yes | Section 4.3.5 |
> | GET | yes | yes | Section 4.3.1 |
> | HEAD | yes | yes | Section 4.3.2 |
> | OPTIONS | yes | yes | Section 4.3.7 |
> | POST | no | no | Section 4.3.3 |
> | PUT | no | yes | Section 4.3.4 |
> | TRACE | yes | yes | Section 4.3.8 |
> +---------+------+------------+---------------+
>
> Corrected Text
> --------------
> 8.1.1. Procedure
>
> HTTP method registrations MUST include the following fields:
>
> o Method Name (see Section 4)
>
> o Safe ("yes" or "no", see Section 4.2.1)
>
> o Idempotent ("yes" or "no", see Section 4.2.2)
>
> o Cacheable ("yes" or "no", see Section 4.2.3)
>
> o Pointer to specification text
>
> Values to be added to this namespace require IETF Review (see
> [RFC5226], Section 4.1).
>
> …
>
> 8.1.3. Registrations
>
> The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
> populated with the registrations below:
>
> +---------+------+------------+-----------+---------------+
> | Method | Safe | Idempotent | Cacheable | Reference |
> +---------+------+------------+-----------+---------------+
> | CONNECT | no | no | no | Section 4.3.6 |
> | DELETE | no | yes | no | Section 4.3.5 |
> | GET | yes | yes | yes | Section 4.3.1 |
> | HEAD | yes | yes | yes | Section 4.3.2 |
> | OPTIONS | yes | yes | no | Section 4.3.7 |
> | POST | no | no | yes | Section 4.3.3 |
> | PUT | no | yes | no | Section 4.3.4 |
> | TRACE | yes | yes | no | Section 4.3.8 |
> +---------+------+------------+-----------+---------------+
>
> Notes
> -----
> HTTP Methods have 3 boolean properties, all of which 8.1.2 says a
> registration needs to define, but only 2 of them were included in the
> registry.
>
> 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
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7231 (draft-ietf-httpbis-p2-semantics-26)
> --------------------------------------
> Title : Hypertext Transfer Protocol (HTTP/1.1): Semantics
> and Content
> Publication Date : June 2014
> Author(s) : R. Fielding, Ed., J. Reschke, Ed.
> Category : PROPOSED STANDARD
> Source : Hypertext Transfer Protocol Bis APP
> Area : Applications
> Stream : IETF
> Verifying Party : IESG
>
Received on Sunday, 25 March 2018 00:49:17 UTC