Draft: draft-ietf-ppm-dap

Commentary: ( 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 is n'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 should n't be cached . And if we ever encounter an HTTP client that does cache requests , I do n'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 : 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 . one place in the DAP spec that does n'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 ca n'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 . ) 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 . ) 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  '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 .
Paragraph (version A):
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
"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
"prep_msg", or is marked as finished if the VDAF preparation process
is finished for the report share.
Paragraph (version B):
The message is a sequence of PrepareStep values, the order of which
matches that of the ReportShare values in
"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
"prep_msg", or is marked as finished if the VDAF preparation process
is finished for the report share.