Original text:
JWS objects sent in ACME requests MUST meet the following additional criteria:  The JWS MUST NOT have the value "none" in its "alg" field <del> The JWS MUST NOT have multiple signatures. </del>  The JWS MUST NOT have a Message Authentication Code (MAC)-based algorithm in its "alg" field  The JWS Protected Header MUST include the following fields: "alg" (Algorithm) document returned with the error MUST include an "algorithms" field with an array of supported "alg" values. <del> 6.3. The JSON Web Signature (JWS) specification RFC7515 contains multiple JWS serialization formats.  When sending an ACME request with a non- empty body, an ACME client implementation MUST use the HTTP Content- Type RFC7231 header to indicate which JWS serialization format is used for encapsulating the ACME request payload.  The following Content-Type values may be used for this purpose: "application/jose": The JWS Compact Serialization RFC7515 MUST be used. The JWS Payload MUST NOT be detached. The JWS Unencoded Payload Option RFC7797 MUST NOT be used. "application/jose+json": Either the JWS Flattened JSON Serialization RFC7515 or the JWS General JSON Serialization RFC7515 MUST be used. The JWS Payload MUST NOT be detached. </del>  <del> The JWS Unencoded Payload Option RFC7797 MUST NOT be used. The JWS Unprotected Header RFC7515 SHOULD NOT be used. In the examples below, JWS objects are shown in the Flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so that the content is readable. 6.4. </del>  It is common in deployment for the entity terminating TLS for HTTPS to be different from the entity operating the logical HTTPS server, provided to clients and having the resource check that requests have the same string in their "url" header parameter. <del> 6.4.1. </del>  The "url" header parameter specifies the URL RFC3986 to which this JWS object is directed.  The "url" header parameter MUST be carried in the protected header of the JWS.  The value of the "url" header parameter MUST be a string representing the URL. <del> 6.5. </del>  In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism value for each response, keep a list of issued nonces, and strike nonces from this list as they are used. <del> 6.5.1. </del>  The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future The Replay-Nonce header field SHOULD NOT be included in HTTP request messages. <del> 6.5.2. </del>  The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce" according to this encoding, then the verifier MUST reject the JWS as malformed. <del> 6.6. </del>  Creation of resources can be rate limited by ACME servers to ensure fair usage and prevent abuse.  Once the rate limit is exceeded, the "Link" header pointing to documentation about the specific rate limit that was hit, using the "help" link relation type. <del> 6.7. </del>  Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. example, an "error of type 'badCSR'" refers to an error document with "type" value "urn:ietf:params:acme:error:badCSR". <del> 6.7.1. </del>  Sometimes a CA may need to return multiple errors in response to a request.  Additionally, the CA may need to attribute errors to

Reviewer comments:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.

Revised text:
JWS objects sent in ACME requests MUST meet the following additional criteria: <ins> The JWS MUST be in the Flattened JSON Serialization </ins> The JWS MUST NOT have the value "none" in its "alg" field  <ins> The JWS MUST NOT have multiple signatures The JWS Unencoded Payload Option RFC7797 MUST NOT be used The JWS Unprotected Header RFC7515 MUST NOT be used </ins> The JWS MUST NOT have a Message Authentication Code (MAC)-based algorithm in its "alg" field <ins> The JWS The JWS Payload MUST NOT be detached </ins> The JWS Protected Header MUST include the following fields: "alg" (Algorithm) document returned with the error MUST include an "algorithms" field with an array of supported "alg" values.  <ins> Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the "Content-Type" header field set to "application/jose+json".  If a request does not meet this requirement, then the server MUST return a response with status code 415 (Unsupported Media Type). </ins>  <ins> 6.3. </ins> It is common in deployment for the entity terminating TLS for HTTPS to be different from the entity operating the logical HTTPS server, provided to clients and having the resource check that requests have the same string in their "url" header parameter.  <ins> 6.3.1. </ins> The "url" header parameter specifies the URL RFC3986 to which this JWS object is directed.  The "url" header parameter MUST be carried in the protected header of the JWS.  The value of the "url" header parameter MUST be a string representing the URL.  <ins> 6.4. </ins> In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism value for each response, keep a list of issued nonces, and strike nonces from this list as they are used.  <ins> 6.4.1. </ins> The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future The Replay-Nonce header field SHOULD NOT be included in HTTP request messages.  <ins> 6.4.2. </ins> The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce" according to this encoding, then the verifier MUST reject the JWS as malformed.  <ins> 6.5. </ins> Creation of resources can be rate limited by ACME servers to ensure fair usage and prevent abuse.  Once the rate limit is exceeded, the "Link" header pointing to documentation about the specific rate limit that was hit, using the "help" link relation type.  <ins> 6.6. </ins> Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. example, an "error of type 'badCSR'" refers to an error document with "type" value "urn:ietf:params:acme:error:badCSR".  <ins> 6.6.1. </ins> Sometimes a CA may need to return multiple errors in response to a request.  Additionally, the CA may need to attribute errors to