Editorial

draft-ietf-ppm-dap.md

@@ -2174,10 +2174,10 @@ Changing a collection job's parameters is illegal, so further requests to
 `collection-job-id` but with a different `CollectionJobReq` in the body MUST
 fail with an HTTP client error status code.
 
-~~~ tls-presentation
 The Leader responds to `CollectionJobReq`s with a `CollectionJobResp`, which is
 structured as follows:
-~~~
+
+~~~ tls-presentation
 enum {
   processing(0),
   finished(1),
@@ -2223,17 +2223,18 @@ structure includes the following:
   Collector (see {{aggregate-share-encrypt}}).
 
 If the Leader finds the `CollectionJobReq` to be valid, it immediately responds
-with HTTP status 201 Created with a body containing a `CollectionJobResp`. The
-`status` field is set to `processing`. The Leader SHOULD include a Retry-After
+with HTTP status 201 Created with a body containing a `CollectionJobResp` with
+the `status` field set to `processing`. The Leader SHOULD include a Retry-After
 header field to suggest a polling interval to the Collector.
 
 After receiving the response to its `CollectionJobReq`, the Collector
-periodically makes HTTP GET requests to the same collection job URI to check on
-the status of the collect job and eventually obtain the result. The Leader
-responds to GET requests with HTTP status 200 and the `status` field reflecting
-the current state of the job. When the collection job is `processing`, the
-response SHOULD include a Retry-After header field to suggest a polling interval
-to the Collector.
+periodically makes HTTP GET requests 
+`/tasks/{task-id}/collection_jobs/{collection-job-id}` to check on the status
+of the collect job and eventually obtain the result. The Leader responds to GET
+requests with HTTP status 200 and the `status` field reflecting the current
+state of the job. When the collection job is `processing`, the response SHOULD
+include a Retry-After header field to suggest a polling interval to the
+Collector.
 
 The Leader then begins working with the Helper to aggregate the reports
 satisfying the query (or continues this process, depending on the VDAF) as
@@ -2253,8 +2254,8 @@ errors.
 
 Once both aggregate shares are successfully obtained, the Leader responds to
 subsequent HTTP GET requests with the `status` field set to `finished` and the
-`Collection` field populated accordingly. The Collector stops polling once
-receiving this final request.
+`Collection` field populated with the encrypted aggregate shares. The Collector
+stops polling once receiving this final request.
 
 If obtaining aggregate shares fails, then the Leader responds to subsequent HTTP
 GET requests to the collection job with an HTTP error status and a problem