search

ietf-wg-ppm / draft-ietf-ppm-dap-taskprov

Define DAP extension for in-band task provisioning.
Other
2 stars 3 forks source link

DAP Error Addition #29

Closed bhalleycf closed 3 weeks ago

bhalleycf commented 1 year ago

This is ultimately something for the DAP spec, but as it came up in the context of taskprov we thought we'd discuss it here first. We added a boolean config variable to control whether or not taskprov was allowed, but there is no good standard DAP error for operation refused / denied / forbidden due to local policy. Perhaps we can add such an error to the spec?

cjpatton commented 1 year ago

It sounds like you'd like to see an explicit "I have disabled this extension" signal? I wonder if this is actually needed, given how the spec currently works.

tgeoghegan commented 1 year ago

I think HTTP already gives us some good tools for this case. HTTP 422 Unprocessable Content or maybe 415 Unsupported Media Type appear to have the right semantics. An implementation could then choose to include a problem document in the response body explaining exactly why the request was rejected (such as an unsupported extension). DAP allows for using problem types beyond the ones listed in the specification:

This list is not exhaustive. The server MAY return errors set to a URI other than those defined above.

I don't think DAP should define a problem type specifically for unsupported extensions, unless there's some specific action that a client would automatically take in response to such an error. If it's just about providing a sufficiently descriptive errors for operators to notice a problem and do something about it, then HTTP and RFC 9457 problem details are already flexible enough for that without any additional text in DAP.

cjpatton commented 3 weeks ago

The latest DAP version now covers this case:

If the Leader's input share contains an unrecognized extension, or if two extensions have the same ExtensionType, then the Leader MAY abort the upload request with error "invalidMessage". Note that this behavior is not mandatory because it requires the Leader to decrypt its input share.