Change:
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.

Discussion:
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> <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 <del> "urn:ietf:params:ppm:error:unrecognizedMessage". </del> <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 <del> "message/ppm-aggregate-initialize-req".  In addition, this request </del> <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 <del> the AggregateInitializeResp and media type is "message/ppm-aggregate- </del> <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 <del> "message/ppm-aggregate-continue-req".  In addition, this request MUST </del> <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 <del> AggregateContinueResp and media type is "message/ppm-aggregate- </del> <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: <del> HpkeConfig hpke-config: "application/ppm-hpke-config" </del> <ins> HpkeConfig hpke-config: "application/dap-hpke-config" </ins> <del> Report upload-request: "message/ppm-report" </del> <ins> Report upload-request: "message/dap-report" </ins> <del> AggregateInitializeReq collect-flow: "message/ppm-aggregate- </del> <ins> AggregateInitializeReq collect-flow: "message/dap-aggregate- </ins> initialize-req" <del> AggregateInitializeResp collect-flow: "message/ppm-aggregate- </del> <ins> AggregateInitializeResp collect-flow: "message/dap-aggregate- </ins> initialize-resp" <del> AggregateContinueReq collect-flow: "message/ppm-aggregate- </del> <ins> AggregateContinueReq collect-flow: "message/dap-aggregate- </ins> continue-req" <del> AggregateContinueResp collect-flow: "message/ppm-aggregate- </del> <ins> AggregateContinueResp collect-flow: "message/dap-aggregate- </ins> continue-resp" <del> AggregateShareReq collect-flow: "message/ppm-aggregate-share-req" </del> <ins> AggregateShareReq collect-flow: "message/dap-aggregate-share-req" </ins> <del> AggregateShareResp collect-flow: "message/ppm-aggregate-share- </del> <ins> AggregateShareResp collect-flow: "message/dap-aggregate-share- </ins> resp" <del> CollectReq collect-flow: "message/ppm-collect-req" </del> <ins> CollectReq collect-flow: "message/dap-collect-req" </ins> <del> CollectResp collect-flow: "message/ppm-collect-resp" </del> <ins> CollectResp collect-flow: "message/dap-collect-resp" </ins> The definition for each media type is in the following subsections.