Original text:
7.1.  This document requests creation of a new registry for extensions to the Upload protocol.  This registry should contain the following columns: [TODO: define how we want to structure this registry when the time comes] <del> 7.2. </del>  The following value [will be/has been] registered in the "IETF URN Sub- namespace for Registered Protocol Parameter Identifiers"

Reviewer comments:
NAME -- is it better practice to define media types per protocol message, or to define a single media type for all protocol messages?
Generally, if they're different formats -- e.g., they have different schema, or just different syntax -- they need different media types (or an explicitly generic one like ). If it's one format that has different uses, you can give it a single media type and then switch contexts based upon internal flags. The real question, though, is whether you have any potential for use cases where it's important for generic software that's handling these messages to do different things based upon the media type.
I don't think there'd ever be generic software using these types (beyond the HpkeConfig?). Most messages are meant to be consumed by PPM and PPM alone. I moved protocol messages to the "message" registry space and kept the HpkeConfig in the application type space, and also left all intended usage fields as COMMON. I also added an open issue to have someone more familiar with these registries give these allocation requests a review. NAME this should be good to go based on the above.
Currently, DAP uses the following media types (defined in section 7.1): Note that the first uses the top-level type, while the remainder use the top-level type. For consistency, I suggest we use the same top-level type for all messages. Which type is more appropriate? Per : is for "either uninterpreted binary data or information to be processed by an application" is for "an encapsulated message"; all of the motivating examples (see section 5.2) are around encaspulating one message format inside another, or fragmenting a message into multiple chunks. provides further guidance that "multipart and message are composite types; that is, they provide a means of encapsulating zero or more objects, each one a separate media type." Given that DAP messages are not a method of encapsulating a message of a different type, I suggest that is the more appropriate top-level type to use. This is also supported by the rather large number of media types vs the relatively tiny number of media types in . (this issue fell out of discussion on URL)
Agreed, seems better.
The types were chosen in PR on a tentative basis, and marked with "OPEN ISSUE: Solicit review of these allocations from domain experts." Based on the encapsulation reasoning, I agree that be most appropriate for our media types.
LGTM except for the hed.

Revised text:
7.1. <ins> This specification defines the following protocol messages, along with their corresponding media types types: HpkeConfig task-configuration: "application/ppm-hpke-config" Report upload-request: "message/ppm-report" AggregateReq aggregate-request: "message/ppm-aggregate-req" AggregateResp aggregate-request: "message/ppm-aggregate-resp" OutputShareReq output-share-request: "message/ppm-output-share- req" OutputShareResp output-share-request: "message/ppm-output-share- resp" CollectReq pa-collect: "message/ppm-collect-req" CollectResp pa-collect: "message/ppm-collect-req" The definition for each media type is in the following subsections. Protocol message format evolution is supported through the definition of new formats that are identified by new media types. IANA [shall update / has updated] the "Media Types" registry at https://www.iana.org/assignments/media-types with the registration information in this section for all media types listed above. [OPEN ISSUE: Solicit review of these allocations from domain experts.] 7.1.1. 7.1.2. 7.1.3. 7.1.4. 7.1.5. 7.1.6. 7.1.7. 7.1.8. 7.2. </ins> This document requests creation of a new registry for extensions to the Upload protocol.  This registry should contain the following columns: [TODO: define how we want to structure this registry when the time comes]  <ins> 7.3. </ins> The following value [will be/has been] registered in the "IETF URN Sub- namespace for Registered Protocol Parameter Identifiers"