Don't require the Client to advertise the task config in every upload request

[cjpatton]

Currently the Client always advertised the task config in a header. We can save on bandwidth by having the Leader ask the Client for the task config only if it doesn't recognize the task.

We could consider doing something similar for the aggregation and collection flows, but (1) the bandwidth savings are less compelling and (2) we would probably need a signal that the sender (e.g., the Leader in the aggregation flow) is using taskprov.

Originally suggested by @martinthomson on the mailing list.

[cjpatton]

I propose we do nothing about the aggregation and collection flows. For the upload flow, I think the following is sufficient:

The Client follows the taskprov-upload protocol as usual, except the "dap-taskprov" header has an empty value.* If the Leader doesn't recognize the task, it aborts with "invalidTask". (Optionally, the problem detail could indicate that it hasn't configured the task yet.) The Client then retries with the "dap-taskprov" header with the serialized task configuration as the value.

---

• I'm not quite sure if it's valid for an HTTP header to have an empty value. If not, then we can just have some short, sentinel value that the Leader interprets as empty.

[martinthomson]

I'm not quite sure if it's valid for an HTTP header to have an empty value

It is valid, but it is very much discouraged. Omitting fields is preferable. But then I have to ask why you are using fields, when this is more rightly a property of the payload. See https://www.rfc-editor.org/rfc/rfc9205.html#name-specifying-http-header-fiel

[cjpatton]

Requirement: If the Leader speaks both taskprov and non-taskprov (this will usually be the case), then it needs some way to distinguish upload requests for taskprov tasks from all other upload requests.

If we stick the task config in the body, then we would need to encode the body such that the Leader can distinguish between (report, task_config) for taskprov tasks and report for other tasks. Further, the encoding will need to be backwards compatible, i.e., non-taskprov tasks should have no change to the request body. It's not immediately clear to me how to do this.

The "dap-taskprov" header is nice because it encodes intent in a way that's backwards compatible. Indeed, I think this is more or less the same reasoning as https://www.rfc-editor.org/rfc/rfc9205.html#section-4.7-2.3.

One potential option is to just omit the "dap-taskprov" header. We would lose a bit of information here, because we can't distinguish between unreocgnized tasks and tasks that have not yet been configured via taskprov. However I don't really know how useful this is. (@wangshan may have some insight here.)

Another option would be to encode the Client's intent in the header. In particular it would have one of two values:"

• None - please ask me to retry with the task config if you don't already have it
• Some(task_config)

[wangshan]

@martinthomson Having task_config in header also gives us the bandwidth save without making a wire breaking change in aggregate flow, since putting task_config in each reportShare will be very wasteful in aggregate flow, and there's no extension struct defined for aggregate flow yet.

I think @cjpatton's solution is valid, I'll add that the re-try behaviour should be optional, for clients that don't want to/unable perform re-tries. If having empty header is very desirable, then perhaps adding a constant as content to indicate taskprov opt-in, for eg. the codepoint of taskprov extension?

I also agree this is mainly an upload flow issue, not much benefit to optimize aggregate flow.

[wangshan]

One potential option is to just omit the "dap-taskprov" header. We would lose a bit of information here, because we can't distinguish between unreocgnized tasks and tasks that have not yet been configured via taskprov. However I don't really know how useful this is. (@wangshan may have some insight here.)

It's probably not crucial. In either case the leader will have to abort. But unless we want to save a few bytes, I think having explicit information is always better than implicit.

[bemasc]

Is there any work planned on this issue? It would be nice to get the essential protocol components sorted out if you are still seeking adoption in PPM.

[cjpatton]

We're still interested in getting this adopted. We can definitely knock this out ahead of IETF 120.