Code change:
otherwise intended.  The server MAY only support a limited number of methods. <del> The request MUST include the "Upload-Incomplete" header field (upload-incomplete).  It MUST be set to true if the end of the request body is not the end of the upload.  Otherwise, it MUST be set to false.  This header field can be used for request identification by a server.  The request MUST NOT include the "Upload-Offset" header. </del> <ins> The request MUST include the "Upload-Complete" header field (upload- complete).  It MUST be set to false if the end of the request body 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 server.  The request MUST NOT include the "Upload-Offset" header. </ins> If the request is valid, the server SHOULD create an upload resource. If so, the server MUST include the "Location" header in the response

Related discussion:
text: Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it."