Change:
3.3.1. The client sends a GET request to <del> "[leader]/[version]/[task_id]/upload_start", where "[version] == PATask.version" and "[task_id] == PATask.id".  [TODO: Decide if adding the protocol version and task id to the URL is the right way to go.  Instead, we may want to make this a POST with a body that specifies the PATask.  (See issue#61.)] The leader respond with status 200 and the following message: </del> <ins> "[leader]/[version]/[task_id]/upload_start", where "[task_id] == PATaskID".  [TODO: Decide if adding the protocol version and task id to the URL is the right way to go.  Instead, we may want to make this a POST with a body that specifies the task id.  (See issue#61.)] The leader respond with status 200 and the following message: </ins> The message includes the PA parameters the client will use to generate its report.  It also includes a protocol-specific message,

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.