Original text:
3.1. <del> [[OPEN ISSUE: Align this with best practice, cribbing from ACME.]] Errors SHOULD be reported in PPM at the HTTP layer, using an HTTP response code of 400.  The response payload is a Alert structure: where "task_id" is the associated PPM task (this value is always known, see task-configuration) and "payload" contains a string indicating the error that occurred.  When sent by an aggregator in response to an HTTP request, the response status is 400.  When sent in a request to an aggregator, the URL is always "[aggregator]/error", where "[aggregator]" is the URL of the aggregator endpoint. [[OPEN ISSUE: What is the URL? https://github.com/abetterinternet/ prio-documents/issues/108]] The following list defines a set of common errors. The message type for the payload of each request and response is unique for a given URL.  If ever a client, aggregator, or collector receives a request or response to a request with a malformed payload, then the receiver aborts and alerts the peer with "unrecognized message". Each POST request to an aggregator contains a "TaskID".  If the aggregator does not recognize the task, i.e., it can't find a "Param" for which the derived task ID matches the "TaskID", then it aborts and alerts the peer with "unrecognized task". [[TODO: Add error table here.]] </del>  This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various [TODO: define how we want to structure this registry when the time comes]  8. The text in message-transport is based extensively on

Reviewer comments:
ACME has a pretty well defined error structure, including RFC 8707 problem documents. We should look at adopting that.
Fixed by

Revised text:
3.1.  <ins> Errors can be reported in PPM both at the HTTP layer and within challenge objects as defined in iana-considerations.  PPM 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 status code 405 (Method Not Allowed). When the server responds with an error status, it SHOULD provide additional information using a problem document RFC7807.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the PPM URN namespace "urn:ietf:ppm:acme:error:"): This list is not exhaustive.  The server MAY return errors set to a URI other than those defined above.  Servers MUST NOT use the PPM URN namespace for errors not listed in the appropriate IANA registry (see ppm-urn-space).  Clients SHOULD display the "detail" field of all errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated PPM task ID (this value is always known, see task-configuration). In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For example, an "error of type 'unrecognizedMessage'" refers to an error document with "type" value "urn:ietf:params:acme:error:unrecognizedMessage". </ins> This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various [TODO: define how we want to structure this registry when the time comes] <ins> 7.2. The following value [will be/has been] registered in the "IETF URN Sub- namespace for Registered Protocol Parameter Identifiers" registry, following the template in RFC3553: Initial contents: The types and descriptions in the table in errors above, with the Reference field set to point to this specification. </ins> 8. The text in message-transport is based extensively on