Change:
(see that issue for justification of this change)
both include the relevant aggregation job ID; but in both cases, the includes the aggregation job ID, the response will always reflect the aggregation job ID that was included in the request, and a request is always paired with a response by means of being part of the same HTTP request/response. This looks to be unnecessary communication overhead--if that's accurate, I think we can just drop these fields.
I wonder if a better design is to pull the aggregation job ID out of the DAP structure and make it a query parameter for the URL, e.g., , for two reasons: (1) the URL isn't echoed in the response, achieving the desired property of this change, and (2) this avoids any caching headaches, since different each aggregate init request would have a different URL. Thoughts?
I think caching is a non-issue, because requests to are POSTs, and POSTs are not required to be idempotent (hence not cacheable). That said I kind of like the idea of hoisting the aggregation job ID into the request URL. However, I think it'd be appropriate to put the aggregation job ID in the path (i.e., ), since the job ID is part of the resource being acted on. At that point, I think we might want to revisit all the DAP endpoints. Currently, we have , and , which are all verbs. HTTP urges us to think about , which ought to be nouns, and we should let the HTTP method be the verb. So instead of POST to , maybe we want POST to , and instead of , we want and so on. However all of that is far beyond the scope of this issue.
I'm not so sure about the proposed benefit to caching -- the relevant requests are s, so they shouldn't be cached. And if we ever encounter an HTTP client that does cache requests, I don't including the IDs as query params will help: the endpoint is used for all aggregation messages (initialization and continue), so we'd still run into potential caching headaches on aggregate continue requests since they'd be using identical URLs to the aggregate initialization requests. That said, perhaps this change is desirable from the perspective of fitting HTTP semantics more closely. A few thoughts: Almost all messages include all relevant data in the HTTP body, rather than using the query parameter. We'd probably want to decide on a rule for what goes into query parameters vs the body, and apply it to all messages for consistency. The one place in the DAP spec that doesn't place all request information in the body is the request, which places the task ID as a query parameter. This is done because we want to use HTTP caching for these requests, which implies using , and can't reliably transmit a body. (IMO, if/when the HTTP verb is standardized+practically usable, it would be preferable to move the parameters to the request body, for consistency.) For aggregate initialization/continue messages specifically, IMO we'd want to move the task ID to the query parameter, too, since the task ID is effectively another part of the aggregation job identifier. (...depending on how the discussion in goes.) Placing this ID in the body allows it to be transmitted raw/unencoded. Placing the ID in the query parameters would require some URL-safe encoding, such as base64url, which would cost a small but non-negligible number of bytes. All that said, IMO I kinda like keeping all of the request parameters together in one place, and IMO the body is a slightly nicer place to put the request parameters than the URL query parameter (since we can transmit with whatever encoding we want, saving a few bytes).
Yeah, sorry, I forgot these were POSTs.
I like Tim's idea of making the IDs part of the URL path if we move the IDs out of the request body, but also agree that a larger refactoring of the URL layout is beyond the scope of this issue.
Agreed that these are redundant with the current design, so I'm OK merging this as-is. Let's split out how we convey task and job parameters (via URL or application message or whatever) to a separate issue.

Discussion:
AggregateInitializeResp message to complete its initialization.  This message is structured as follows: <del> The "job_id" parameter is equal to AggregateInitializeReq.job_id. The rest of the message is a sequence of PrepareStep values, the order of which matches that of the ReportShare values in </del> <ins> The message is a sequence of PrepareStep values, the order of which matches that of the ReportShare values in </ins> "AggregateInitializeReq.report_shares".  Each report that was marked as invalid is assigned the PrepareStepResult "failed".  Otherwise, the PrepareStep is either marked as continued with the output