What error should unimplemented commands return?

[gsnedders]

https://w3c.github.io/webdriver-bidi/#handle-an-incoming-message currently says, in the case when it doesn't match the remote end definition (and there's no obligation to include all possible things in the remote end definition):

If parsed is a map and parsed["method"] exists and is a string, but parsed["method"] is not in the set of all command names, set error code to unknown command.

And:

The set of all command names is a set containing all the defined command names, including any belonging to extension modules.

That this says "defined command names" is kinda unclear — if I don't support Web Bluetooth, is the bluetooth.handleRequestDevicePrompt command still a defined command name?

What if I don't support the browser.getClientWindows, because while I've made bugfixes in line with spec updates, I haven't added support for the commands added in d620065?

I'd expect this should be "but parsed["method"] is not in a command name supported by the remote end, set error code to unknown command"?

And if people have concerns about the open-ended nature of that, we could add a note to make it clear that it is required to support all commands defined in this specification?

[OrKoN]

I agree it is not very clear. My interpretation for:

The set of all command names is a set containing all the defined command names, including any belonging to extension modules.

is that it only includes commands defined in specifications that the remote end implements. So Web Bluetooth commands are not in that list, if the remote end does not implement the Web Bluetooth specification. Extension modules here refer to (unspecified) extensions provided by the implementation and not the modules defined by external specifications.

I think it is preferred if implementations handle all commands defined in a specification returning the "unsupported operation" errors only for commands/scenarios that explicitly allow that. Perhaps this should be clarified in the spec text like you suggest. As for commands that are not yet implemented, I think returning either the unknown or unsupported error is fine as a temporary implementation.