Original text:
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 DAP <del> URN namespace "urn:ietf:params:ppm:error:"): </del>  This list is not exhaustive.  The server MAY return errors set to a URI other than those defined above.  Servers MUST NOT use the DAP URN 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 <del> "urn:ietf:params:ppm:error:unrecognizedMessage". </del>  This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various Let "[aggregator]" denote the helper's API endpoint.  The leader sends a POST request to "[aggregator]/aggregate" with its AggregateInitializeReq message as the payload.  The media type is <del> "message/ppm-aggregate-initialize-req".  In addition, this request </del>  MUST be authenticated as described in https-sender-auth. 4.3.1.2. is finished for the report share. The helper's response to the leader is an HTTP 200 OK whose body is <del> the AggregateInitializeResp and media type is "message/ppm-aggregate- </del>  initialize-resp". Upon receipt of a helper's AggregateInitializeResp message, the "AggregateContinueReq.task_id"'s parameters except its own, the leader sends a POST request to "[aggregator]/aggregate" with AggregateContinueReq as the payload and the media type set to <del> "message/ppm-aggregate-continue-req".  In addition, this request MUST </del>  be authenticated as described in https-sender-auth. 4.3.2.2. The order of AggregateContinueResp.prepare_shares MUST match that of the PrepareStep values in "AggregateContinueReq.prepare_shares".  The helper's response to the leader is an HTTP 200 OK whose body is the <del> AggregateContinueResp and media type is "message/ppm-aggregate- </del>  continue-resp".  The helper then awaits the next message from the leader. This specification defines the following protocol messages, along with their corresponding media types types: <del> HpkeConfig hpke-config: "application/ppm-hpke-config" </del>  <del> Report upload-request: "message/ppm-report" </del>  <del> AggregateInitializeReq collect-flow: "message/ppm-aggregate- </del>  initialize-req" <del> AggregateInitializeResp collect-flow: "message/ppm-aggregate- </del>  initialize-resp" <del> AggregateContinueReq collect-flow: "message/ppm-aggregate- </del>  continue-req" <del> AggregateContinueResp collect-flow: "message/ppm-aggregate- </del>  continue-resp" <del> AggregateShareReq collect-flow: "message/ppm-aggregate-share-req" </del>  <del> AggregateShareResp collect-flow: "message/ppm-aggregate-share- </del>  resp" <del> CollectReq collect-flow: "message/ppm-collect-req" </del>  <del> CollectResp collect-flow: "message/ppm-collect-resp" </del>  The definition for each media type is in the following subsections.

Reviewer comments:
This change is basically a search-and-replace for /ppm/dap/. However, I have also re-aligned the context strings to match the next draft that will be cut (-01). I think the change is mostly correct, my main concern is the "URN Sub-namespace for PPM (urn:ietf:params:dap)" section. : Does it make sense for all drafts in the PPM WG to share the namespace, or do we want to define one specifically for DAP?
Before merging I would appreciate an answer on the question I raised above. I want to make sure the URN bits are correct.
Separate namespaces seems better, especially if we're thinking of DAP and STAR. Names are cheap, after all.
Separate namespaces, because otherwise I think we'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference. We should avoid spreading the specification across multiple documents more than necessary. Maybe including the WG in the URN path like helps?
Here's the RFC defining URL It's pretty loosely structured, and the existing sub-namespaces from published RFCs appear to just be named after protocols and formats, not working groups. URL
I took NAME suggestion of prefixing the dap space with ppm.

Revised text:
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 DAP  <ins> URN namespace "urn:ietf:params:ppm:dap:error:"): </ins> This list is not exhaustive.  The server MAY return errors set to a URI other than those defined above.  Servers MUST NOT use the DAP URN 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  <ins> "urn:ietf:params:ppm:dap:error:unrecognizedMessage". </ins> This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various Let "[aggregator]" denote the helper's API endpoint.  The leader sends a POST request to "[aggregator]/aggregate" with its AggregateInitializeReq message as the payload.  The media type is  <ins> "message/dap-aggregate-initialize-req".  In addition, this request </ins> MUST be authenticated as described in https-sender-auth. 4.3.1.2. is finished for the report share. The helper's response to the leader is an HTTP 200 OK whose body is  <ins> the AggregateInitializeResp and media type is "message/dap-aggregate- </ins> initialize-resp". Upon receipt of a helper's AggregateInitializeResp message, the "AggregateContinueReq.task_id"'s parameters except its own, the leader sends a POST request to "[aggregator]/aggregate" with AggregateContinueReq as the payload and the media type set to  <ins> "message/dap-aggregate-continue-req".  In addition, this request MUST </ins> be authenticated as described in https-sender-auth. 4.3.2.2. The order of AggregateContinueResp.prepare_shares MUST match that of the PrepareStep values in "AggregateContinueReq.prepare_shares".  The helper's response to the leader is an HTTP 200 OK whose body is the  <ins> AggregateContinueResp and media type is "message/dap-aggregate- </ins> continue-resp".  The helper then awaits the next message from the leader. This specification defines the following protocol messages, along with their corresponding media types types:  <ins> HpkeConfig hpke-config: "application/dap-hpke-config" </ins>  <ins> Report upload-request: "message/dap-report" </ins>  <ins> AggregateInitializeReq collect-flow: "message/dap-aggregate- </ins> initialize-req"  <ins> AggregateInitializeResp collect-flow: "message/dap-aggregate- </ins> initialize-resp"  <ins> AggregateContinueReq collect-flow: "message/dap-aggregate- </ins> continue-req"  <ins> AggregateContinueResp collect-flow: "message/dap-aggregate- </ins> continue-resp"  <ins> AggregateShareReq collect-flow: "message/dap-aggregate-share-req" </ins>  <ins> AggregateShareResp collect-flow: "message/dap-aggregate-share- </ins> resp"  <ins> CollectReq collect-flow: "message/dap-collect-req" </ins>  <ins> CollectResp collect-flow: "message/dap-collect-resp" </ins> The definition for each media type is in the following subsections.