Hi Eduard, The capabilities PR looks good to me overall. I have a concern with the "oauth2" tag name though.
I also commented [1] in GH but the comment appears to be closed by default :) I believe the term "oauth2" is confusing in this context with respect to RFC 6749 [2] as discussed in depth on another thread [3] The functionality behind the /tokens endpoint is quite specific to the Iceberg REST spec and as the other discussion highlights, there are concerns with respect to OAuth2 interoperability with other OAuth2 servers. What do you think about using a different tag name for it, for example "local-tokens" or "auth-tokens"? Thanks, Dmitri. [1] https://github.com/apache/iceberg/pull/9940/files/15c769a52b85ac4deff5659978c7ffa7802612b0#r1649173934 [2] https://www.rfc-editor.org/rfc/rfc6749 [3] https://lists.apache.org/thread/twk84xx7v0xy5q5tfd9x5torgr82vv50 On Thu, Jun 20, 2024 at 7:28 AM Eduard Tudenhoefner < etudenhoef...@apache.org> wrote: > Hey everyone, > > I'd like to bring up the discussion around describing REST server > capabilities via the */config* endpoint. > There is PR #9940 <https://github.com/apache/iceberg/pull/9940> that > describes the OpenAPI spec changes. > > Mainly we'd like to have a *capabilities* field in the *ConfigResponse* that > allows servers to indicate to clients which capabilities are being > supported. > > So far we have the following capabilities: > > - tables > - views > - remote-signing > - vended-credentials > - multi-table-commit > - register-table > - table-metrics > - oauth2 > > > The general idea behind a capability is that if e.g. a server supports > *views*, then that server must implement all endpoints grouped under that > capability. > It's worth noting that the */config* endpoint is currently being implicit > (meaning that every REST server would have to implement it). > > One discussion point that came up during review is how we want to handle > capabilities and backwards compatibility and what the default capability > would be, since older servers don't know anything about *capabilities* (in > such a case we could assume that the default capabilities would be > *oauth2* / *tables*). > > Are there any other capabilities that we'd like to include in the list? > > Eduard >
