Code change:
Upload appending is used for resuming an existing upload. The request MUST use the "PATCH" method and be sent to the upload <del> resource.  The "Upload-Offset" header field (upload-offset) MUST be </del> <ins> resource.  The "Upload-Offset" field value (upload-offset) MUST be </ins> set to the resumption offset. If the end of the request content is not the end of the upload, the <del> "Upload-Complete" header field (upload-complete) MUST be set to false. </del> <ins> "Upload-Complete" field value (upload-complete) MUST be set to false. </ins> The server SHOULD respect representation metadata received during creation (upload-creation) and ignore any representation metadata received from appending (upload-appending). If the server does not consider the upload associated with the upload <del> resource active, it MUST respond with "404 (Not Found)" status code. </del> <ins> resource active, it MUST respond with a "404 (Not Found)" status code. </ins> The client MUST NOT perform multiple upload transfers for the same <del> upload resource in parallel to avoid race conditions and data loss or corruption.  The server is RECOMMENDED to take measures to avoid parallel upload transfers: The server MAY terminate any creation (upload-creation) or append (upload-appending) for the same upload URL.  Since the client is not allowed to perform multiple transfers in parallel, the server can assume that the previous attempt has already failed.  Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. If the offset in the "Upload-Offset" header field does not match the offset provided by the immediate previous offset retrieval (offset- retrieving), or the end offset of the immediate previous incomplete successful transfer, the server MUST respond with "409 (Conflict)" status code. 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> upload resource in parallel.  This helps avoid race conditions, and data loss or corruption.  The server is RECOMMENDED to take measures to avoid parallel upload transfers: The server MAY terminate any creation (upload-creation) or append (upload-appending) for the same upload URL.  Since the client is not allowed to perform multiple transfers in parallel, the server can assume that the previous attempt has already failed.  Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. If the offset indicated by the "Upload-Offset" field value does not match the offset provided by the immediate previous offset retrieval (offset-retrieving), or the end offset of the immediate previous incomplete successful transfer, the server MUST respond with a "409 (Conflict)" status code. 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 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 status code indicates a success but the offset indicated by 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 </del> <ins> successful status code between 200 and 299 (inclusive).  Servers are RECOMMENDED to use a "201 (Created)" response if not otherwise </ins> specified.  The response MUST NOT include the "Upload-Complete" <del> header with the value of false. </del> <ins> header field with the value set to false. </ins> If the request completes successfully but the entire upload is not <del> yet complete indicated by the "Upload-Complete" header, the server MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Complete" header set to true. If the request includes the "Upload-Complete: ?1" header field and a valid "Content-Length" header field, the client attempts to upload the remaining resource in one request.  In this case, the upload's final size is the sum of the upload's offset and the "Content-Length" header field.  If the server does not have a record of the upload's final size from creation or the previous append, the server MUST record the upload's final size to ensure its consistency.  If the server does have a previous record, that value MUST match the </del> <ins> yet complete indicated by the "Upload-Complete" field value set to false, the server MUST acknowledge it by responding with a "201 (Created)" status code and the "Upload-Complete" field value set to true. If the request includes the "Upload-Complete" field value set to true and a valid "Content-Length" header field, the client attempts to upload the remaining resource in one request.  In this case, the upload's final size is the sum of the upload's offset and the "Content-Length" header field.  If the server does not have a record of the upload's final size from creation or the previous append, the server MUST record the upload's final size to ensure its consistency. If the server does have a previous record, that value MUST match the </ins> upload's final size.  If they do not match, the server MUST reject <del> the request with the "400 (Bad Request)" status code. </del> <ins> the request with a "400 (Bad Request)" status code. </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status

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.