Allow abort for requests for expired tasks

Clients are free to pick any timestamp they wish, even one in the
validity range of a task that has expired. The Aggregators need to
prevent themselves from aggregating such reports indefinitely.

Recommend aborting an upload or aggregation initialization request for
expired tasks.

draft-ietf-ppm-dap.md

@@ -978,11 +978,12 @@ the following parameters associated with it:
   batch mode.
 * `task_start`: The time from which the Clients will start uploading reports to
   a task. Aggregators MUST reject reports with timestamps earlier than
-  `task_start`.
+  `task_start` as described in {{input-share-validation}}.
 * `task_duration`: The duration of a task. The task is considered completed
   after the end time `task_start + task_duration`. Aggregators MUST reject
-  reports that have timestamps later than the end time, and MAY choose to opt
-  out of the task if `task_duration` is too long.
+  reports that have timestamps later than the end time as described in
+  {{input-share-validation}}. In addition, they MAY choose to opt out of the
+  task if `task_duration` is too long.
 * `time_precision`: Clients use this value to truncate their report timestamps;
   see {{upload-flow}}. Additional semantics may apply, depending on the batch
   mode. (See {{batch-validation}} for details.)
@@ -1223,7 +1224,10 @@ Clients SHOULD NOT upload the same measurement value in more than one report if
 the Leader responds with HTTP status code 201 Created.
 
 If the Leader does not recognize the task ID, then it MUST abort with error
-`unrecognizedTask`.
+`unrecognizedTask`. If the task has expired, i.e., `task_start + task_duration`
+is greater than the current time, then it SHOULD abort with error
+`unrecognizedTask`. It may choose to provide leeway for Clients with skewed
+clocks.
 
 The Leader responds to requests whose Leader encrypted input share uses an
 out-of-date or unknown `HpkeConfig.id` value, indicated by
@@ -1652,7 +1656,11 @@ just as the Leader does. If successful, it includes the result in its response
 that the Leader will use to continue preparing the report.
 
 Upon receipt of an `AggregationJobInitReq`, the Helper checks if it recognizes
-the task ID. If not, then it MUST abort with error `unrecognizedTask`.
+the task ID. If not, then it MUST abort with error `unrecognizedTask`. If the
+task is recognized but has expired, i.e., `task_start + task_duration` is
+greater than the current time, then the Helper SHOULD abort with error
+`unrecognizedTask`. It may allow some leeway in case the Leader's clock is
+skewed.
 
 Next, the Helper checks that the report IDs in
 `AggregationJobInitReq.prepare_inits` are all distinct. If two preparation