Code change:
incrementally. 1) If the client is aware that the server supports resumable upload, <del> it can start an upload with the "Upload-Complete: ?0" and the first part of the file. </del> <ins> it can start an upload with the "Upload-Complete" field value set to false and the first part of the file. </ins> <del> 2) Afterwards, the following parts are appended (upload-appending), and the last part of the upload has the "Upload-Complete: ?1" header to indicate the complete transfer. </del> <ins> 2) Subsequently, parts are appended (upload-appending).  The last part of the upload has a "Upload-Complete" field value set to true to indicate the complete transfer. </ins> 4. When a resource supports resumable uploads, the first step is creating the upload resource.  To be compatible with the widest range <del> of resources, this is accomplished by adding a header field to the request that initiates the upload, "Upload-Complete". </del> <ins> of resources, this is accomplished by including the "Upload-Complete" header field in the request that initiates the upload. </ins> As a consequence, resumable uploads support all HTTP request methods that can carry content, such as "POST", "PUT", and "PATCH". <del> Similarly, the response to the upload request can have any response status code.  Both the method(s) and status code(s) supported are determined by the resource. </del> <ins> Similarly, the response to the upload request can have any status code.  Both the method(s) and status code(s) supported are determined by the resource. </ins> "Upload-Complete" MUST be set to false if the end of the request content is not the end of the upload.  Otherwise, it MUST be set to true.  This header field can be used for request identification by a <del> server.  The request MUST NOT include the "Upload-Offset" header. </del> <ins> server.  The request MUST NOT include the "Upload-Offset" header field. </ins> If the request is valid, the server SHOULD create an upload resource. <del> Then, the server MUST include the "Location" header in the response and set its value to the URL of the upload resource.  The client MAY use this URL for offset retrieval (offset-retrieving), upload append (upload-appending), and upload cancellation (upload-cancellation). </del> <ins> Then, the server MUST include the "Location" header field in the response and set its value to the URL of the upload resource.  The client MAY use this URL for offset retrieval (offset-retrieving), upload append (upload-appending), and upload cancellation (upload- cancellation). </ins> Once the upload resource is available, the target resource MAY send <del> an informational response with "104 (Upload Resumption Supported)" status to the client while the request content is being uploaded.  In this informational response, the "Location" header field MUST be set to the upload resource. The server MUST send the "Upload-Offset" header in the response if it considers the upload active, either when the response is a success (e.g. "201 (Created)"), or when the response is a failure (e.g. "409 (Conflict)").  The value MUST be equal to the end offset of the entire upload, or the begin offset of the next chunk if the upload is still incomplete.  The client SHOULD consider the upload failed if the response status code indicates a success but the offset in the "Upload-Offset" header field in the response does not equal to the begin offset plus the number of bytes uploaded in the request. </del> <ins> an informational response with a "104 (Upload Resumption Supported)" status code to the client while the request content is being uploaded.  In this informational response, the "Location" header field MUST be set to the upload resource. The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a success (e.g. "201 (Created)"), or when the response is a failure (e.g. "409 (Conflict)").  The "Upload-Offset" field value MUST be equal to the end offset of the entire upload, or the begin offset of the next chunk if the upload is still incomplete.  The client SHOULD consider the upload failed if the response has a status code that indicates a success but the offset indicated in the "Upload-Offset" field value does not equal the total of begin offset plus the number of bytes uploaded in the request. </ins> If the request completes successfully and the entire upload is complete, the server MUST acknowledge it by responding with a <del> successful status code between 200 and 299 (inclusive).  Server is RECOMMENDED to use "201 (Created)" response if not otherwise specified.  The response MUST NOT include the "Upload-Complete" header with the value of false. </del> <ins> successful status code between 200 and 299 (inclusive).  Servers are RECOMMENDED to use "201 (Created)" unless otherwise specified.  The response MUST NOT include the "Upload-Complete" header field with the value of false. </ins> If the request completes successfully but the entire upload is not <del> yet complete indicated by the "Upload-Complete: ?0" header, the server MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Complete" header set to false. If the request includes the "Upload-Complete: ?1" header field and a valid "Content-Length" header field, the client attempts to upload a fixed-length resource in one request.  In this case, the upload's final size is the value of the "Content-Length" header field and the server MUST record the upload's final size to ensure its consistency. If the client received an informational response with the upload URL, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received. </del> <ins> yet complete, as indicated by an "Upload-Complete" field value of false in the request, the server MUST acknowledge it by responding with the "201 (Created)" status code and an "Upload-Complete" header value set to false. If the request includes an "Upload-Complete" field value set to true and a valid "Content-Length" header field, the client attempts to upload a fixed-length resource in one request.  In this case, the upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a 5xx status is received.  The client SHOULD NOT automatically retry if it receives a 4xx status code. </ins> File metadata can affect how servers might act on the uploaded file. Clients can send representation metadata (see HTTP) in the request that starts an upload.  Servers MAY interpret this metadata or MAY <del> ignore it.  The "Content-Type" header can be used to indicate the MIME type of the file.  The "Content-Disposition" header can be used to transmit a filename.  If included, the parameters SHOULD be either "filename", "filename*" or "boundary". </del> <ins> ignore it.  The "Content-Type" header field (HTTP) can be used to indicate the MIME type of the file.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </ins> 4.1. If the client has no knowledge of whether the resource supports resumable uploads, a resumable request can be used with some <del> additional constraints.  In particular, the "Upload-Complete" header field (upload-complete) MUST NOT be set to false if the server support is unclear.  This allows the upload to function as if it is a regular upload. </del> <ins> additional constraints.  In particular, the "Upload-Complete" field value (upload-complete) MUST NOT be false if the server support is unclear.  This allows the upload to function as if it is a regular upload. </ins> <del> The server SHOULD send the "104 (Upload Resumption Supported)" informational response to the client, to indicate its support for a resumable upload. </del> <ins> Servers SHOULD use the "104 (Upload Resumption Supported)" informational response to indicate their support for a resumable upload request. </ins> <del> The client MUST NOT attempt to resume an upload if it did not receive the "104 (Upload Resumption Supported)" informational response, and it does not have other signals of whether the server supports resumable uploads. </del> <ins> Clients MUST NOT attempt to resume an upload unless they receive "104 (Upload Resumption Supported)" informational response, or have other out-of-band methods to determine server support for resumable uploads. </ins> 4.2.

Related discussion:
text: See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.