Original text:
This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various <del> error conditions. </del>  4. the task ID obtained from the task parameters, encoded in Base 64 with URL and filename safe alphabet with no padding, as specified in sections 5 and 3.2 of RFC4648.  If the aggregator does not recognize <del> the task ID, then it responds with HTTP status code 400 Bad Request and an error of type "unrecognizedTask". </del>  An aggregator is free to use different HPKE configurations for each task with which it is configured.  If the task ID is missing from a measurement value in more than one report if the leader responds with HTTP status code 200 OK and an empty body. <del> If the leader does not recognize the task ID, then it responds with HTTP status code 400 Bad Request and an error of type "unrecognizedTask". </del>  The leader responds to requests whose leader encrypted input share uses an out-of-date "HpkeConfig.id" value, indicated by <del> "HpkeCiphertext.config_id", with HTTP status code 400 Bad Request and an error of type 'outdatedConfig'.  Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </del>  The Leader MUST ignore any report pertaining to a batch that has already been collected.  (See early-input-share-validation for VDAF-specific message for each report share. To begin this process, the helper first checks if it recognizes the <del> task ID, if not then it responds with HTTP status code 400 Bad Request and an error of type "unrecognizedTask".  Then the helper checks that the report IDs in "AggregateInitializeReq.report_shares" are all distinct.  If two ReportShare values have the same report ID, then the helper MUST abort with error "unrecognizedMessage".  If this check succeeds, the helper then attempts to recover each input share in "AggregateInitializeReq.report_shares" as follows: </del>  Decrypt the input share for each report share as described in input-share-decryption. 4.4.2.2. <del> If the helper does not recognize the task ID, then it aborts preparation with HTTP status code 400 Bad Request and an error of type "unrecognizedTask". </del>  Otherwise, the helper continues with preparation for a report share by combining the leader's input message in "AggregateContinueReq" and The named parameters are: "task_id", the DAP task ID.  If the Leader does not recognize the <del> task ID, it MUST abort with HTTP status code 400 Bad Request and error "unrecognizedTask". </del>  "query", the Collector's query.  The indicated query type MUST match the task's query type.  Otherwise, the Leader MUST abort The message contains the following parameters: The DAP task ID.  If the Helper does not recognize the task ID, it <del> MUST abort with HTTP status code 400 Bad Request and error "unrecognizedTask". </del>  The "batch selector", which encodes parameters used to determine the batch being aggregated.  The value depends on the query type

Reviewer comments:
Addresses issue URL
I don't think that's true. : >DAP servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return HTTP status code 405 Method Not Allowed. So maybe we do need to specify that the status should be 400 (client error) and not 500 (server error). FWIW, has several places where it dictates HTTP 400 inline in the text, so I think it's OK for us to do that. I agree we should be consistent about using MUST throughout the document. Curiously, ACME has some examples where the 400 error response is a MUST, but the 200 success response has no all-caps applied to it. :
NAME NAME thanks for the comments, I've specified 400 in the errors section and shortened the words elsewhere.
Error types are either double quoted or code formatted, the text seems to encourage both: But these format are not consistent, some examples: It would be much clearer if we choose one style and make it consistent across the text.
The current protocol text doesn't specify what participants should do when a task ID is not recognized, there are two places unrecognized task are mentioned: In the table, it has: mentions "404 Not Found and an error of type unrecognizedTask", which seems to conflict with most implementation's choice of error code 400 (NAME ) The text should specify error 400 with type is used in every API that receives unrecognized task ID.
This would be useful I think. Would you mind sending a PR, NAME
NAME will do, create this issue to remind myself.
PR merged

Revised text:
This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various  <ins> error conditions.  This implies HTTP status code 400 Bad Request unless explicitly specified otherwise. </ins> 4. the task ID obtained from the task parameters, encoded in Base 64 with URL and filename safe alphabet with no padding, as specified in sections 5 and 3.2 of RFC4648.  If the aggregator does not recognize  <ins> the task ID, then it MUST abort with error "unrecognizedTask". </ins> An aggregator is free to use different HPKE configurations for each task with which it is configured.  If the task ID is missing from a measurement value in more than one report if the leader responds with HTTP status code 200 OK and an empty body.  <ins> If the leader does not recognize the task ID, then it MUST abort with error "unrecognizedTask". </ins> The leader responds to requests whose leader encrypted input share uses an out-of-date "HpkeConfig.id" value, indicated by  <ins> "HpkeCiphertext.config_id", with error of type 'outdatedConfig'. Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </ins> The Leader MUST ignore any report pertaining to a batch that has already been collected.  (See early-input-share-validation for VDAF-specific message for each report share. To begin this process, the helper first checks if it recognizes the  <ins> task ID, if not then it MUST abort with error "unrecognizedTask". Then the helper checks that the report IDs in "AggregateInitializeReq.report_shares" are all distinct.  If two ReportShare values have the same report ID, then the helper MUST abort with error "unrecognizedMessage".  If this check succeeds, the helper then attempts to recover each input share in "AggregateInitializeReq.report_shares" as follows: </ins> Decrypt the input share for each report share as described in input-share-decryption. 4.4.2.2.  <ins> If the helper does not recognize the task ID, then it MUST abort with error "unrecognizedTask". </ins> Otherwise, the helper continues with preparation for a report share by combining the leader's input message in "AggregateContinueReq" and The named parameters are: "task_id", the DAP task ID.  If the Leader does not recognize the  <ins> task ID, it MUST abort with error "unrecognizedTask". </ins> "query", the Collector's query.  The indicated query type MUST match the task's query type.  Otherwise, the Leader MUST abort The message contains the following parameters: The DAP task ID.  If the Helper does not recognize the task ID, it  <ins> MUST abort with error "unrecognizedTask". </ins> The "batch selector", which encodes parameters used to determine the batch being aggregated.  The value depends on the query type