Change:
3.1.1. Each PA protocol is associated with a _PA task_ that specifies the <del> measurements that are to be collected: </del> <ins> measurements that are to be collected.  Associated to each task is a set of _PA Parameters_, encoded by the following "PAParam" structure, which specify the protocol used to verify and aggregate the clients' measurements: </ins> <del> The first field, "version" specifies the version of this document. The second field, "id", is an opaque identifier used by the clients, aggregators, and collector to uniquely identify the PA task at hand. We will call it the _task id_ in the remainder. [TODO: Decide how the "PATask" is configured.  Eventually this will be distributed, in an authenticated manner, from the collector to the other parties.  For now, we just assume this value is negotiated out- of-band.] 3.1.2. Associated to each task are the _PA Parameters_ encoded by the "PAParam" structure: "task": The PA task. "helper_url": The helpers endpoint URL. </del> <ins> "helper_url": The helper's endpoint URL. </ins> "collector_config": The HPKE configuration of the collector (described in hpke-config).  [OPEN ISSUE: Maybe the collector's

Discussion:
by removing the field from each of the protocol messages. Partially addresses by establishing that the task id is derived from the PA parameters for a task. We still need to specify this procedure.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
This seems unnecessary.
The PATask is always the first bit of a protocol message, and the version is the first bit of the PATask. I figured it would be helpful to version each message because messages are carried by HTTP requests. There might be a simpler/better way to do this.
I don't think we should assume that's the case. If we want to have the version not determined at the URL level (a mistake, IMO) then we should have some sort of message wrapper that contains that, rather than overloading PATask.
I'm inclined to agree with NAME we're discussing versioning the whole API in , so PATask doesn't need to also provide version information.

So, setting aside the question of message format versions, is there any value in maintaining a version on PATasks at the protocol level? I say no, because we want to be able to treat different PATasks completely independently and don't otherwise have any notion of a relationship between any two PATasks in the protocol.