Subject: [Editorial Errata Reported] RFC7231 (4436)

From: RFC Errata System <[email-masked]>
Date: Thu, 6 Aug 2015 23:28:58 -0700 (PDT)

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_search.php?rfc=7231&eid=4436

--------------------------------------
Type: Editorial
Reported by: Aron Duby <[email-masked]>

Section: 4.3.5

Original Text
-------------
If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted, a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied,
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

Corrected Text
--------------
If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted; a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied;
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

Notes
-----
Using a semicolon creates a stronger delineation of the different options. If you are just quickly trying to parse what status to return if the delete hasn't happened yet and you quickly read "has not yet been enacted, a 204 (No Content)" you could incorrectly read that as return a 204. The semicolon makes it more obvious that "enacted" is the end of that thought and to scan backwards where as the comma in this instance requires knowing the structure of the rest of the paragraph.

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. 

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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 7 Aug 2015 09:23:14 +0200

> "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".

I disagree, the parsing looks bogus hence suspicious to me this way.
Also there should be no "or" after a semi-colon. If you want to fix
any possible ambiguity you may feel in the original text, then please
write it as an enumerated list and then you can use the semi-colon to
end each list item. It would then give something approximately like
this :

-------
send :

  - a 202 (Accepted) status code if the action will likely succeed
    but has not yet been enacted ;

  - a 204 (No Content) status code if the action has been enacted and
    no further information is to be supplied ;

  - a 200 (OK) status code if the action has been enacted and the
    response message includes a representation describing the status.
-------

Regards,
Willy

---

From: Barry Leiba <[email-masked]>
Date: Fri, 7 Aug 2015 16:07:19 +0200

In English usage, semicolons are used in lists when there are commas
within the list entries.  For example:

(with commas): Clients should do this, that, or the other.

(with semicolons): Clients should do this; that, when idle; or the other.

In the second example, the second list item is "that, when idle", and
it contains a comma.  So semicolons are used to delimit the list in
that case.

In the list in question, there's no need to do that.  Willy's right
that a bullet list might be a better approach for this particular
list.

While the report is incorrect as entered, I think it's worth recording
the bullet-list suggestion for a possible document update, so I'm
going to mark this "Held For Document Update".

Barry, ART AD