Draft: draft-pda-protocol

Commentary: by removing the field from each of the protocol messages . Partially addresses by establishing that the task i d 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 . 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  . 
 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 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 do n'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 we 're discussing versioning the whole API in , so PATask does n'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 do n't otherwise have any notion of a relationship between any two PATasks in the protocol .
Paragraph (version A):
Each round of the protocol corresponds to an HTTP request and
response.  The content type of each request is "application/octet-
stream".  We assume that some transport layer security protocol
(e.g., TLS or QUIC) is used between each pair of parties and that the
server is always authenticated.
Paragraph (version B):
Each round of the protocol corresponds to an HTTP request and
response.  The content type of each request is "application/octet-
stream".  We assume that some transport layer security protocol
(e.g., TLS or QUIC) is used between each pair of parties and that the
server is authenticated.
Paragraph (version A):
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.
Paragraph (version A):
"task": The PA task.
Paragraph (version A):
"helper_url": The helpers endpoint URL.
Paragraph (version B):
"helper_url": The helper's endpoint URL.
Paragraph (version A):
Each POST request to an aggregator contains a "PATask".  If the
aggregator does not recognize the task, i.e., it can't find a
"PAParam" for which "PATask.id == PAParam.task.id", then it aborts
and alerts the peer with "unrecognized task".
Paragraph (version B):
Each POST request to an aggregator contains a "PATaskID".  If the
aggregator does not recognize the task, i.e., it can't find a
"PAParam" for which the derived task id matches the "PATaskID",
then it aborts and alerts the peer with "unrecognized task".