Hi Yufei, OK, I will start the VOTE thread shortly. Stay tuned!
Thanks, Alex On Fri, Feb 20, 2026 at 8:44 PM Yufei Gu <[email protected]> wrote: > > Thanks a lot for working on it, Alex. I think it's ready to open a vote. > Yufei > > > On Thu, Feb 19, 2026 at 4:47 AM Alexandre Dutra <[email protected]> wrote: >> >> Hi all, >> >> The PR to promote the signer endpoint to the main specification has >> now received 3 approvals [1]. A big thank you to Eduard, Prashant and >> Steve for their thorough reviews! >> >> With these approvals in hand, is this the right time to start a VOTE >> thread, or should we wait a bit longer to gather more input and >> reviews? >> >> Thanks, >> Alex >> >> [1]: https://github.com/apache/iceberg/pull/15112 >> >> On Thu, Jan 22, 2026 at 5:26 PM Alexandre Dutra <[email protected]> wrote: >> > >> > Hi all, >> > >> > The PR is up for review: >> > >> > https://github.com/apache/iceberg/pull/15112 >> > >> > Thanks, >> > Alex >> > >> > >> > On Wed, Jan 21, 2026 at 6:49 PM Ryan Blue <[email protected]> wrote: >> > > >> > > A VOTE for REST spec updates usually happens after the changes are >> > > available to review. >> > > >> > > On Wed, Jan 21, 2026 at 9:39 AM Alexandre Dutra <[email protected]> >> > > wrote: >> > >> >> > >> Thank you all! >> > >> >> > >> I think we have an agreement here. I'm happy to start working on the >> > >> PR, but I recall that a VOTE thread is necessary for this type of >> > >> modification. Should we initiate the vote now, or wait until the PR is >> > >> ready for merging (and vote on the PR contents)? >> > >> >> > >> Thanks, >> > >> Alex >> > >> >> > >> On Wed, Jan 21, 2026 at 1:08 AM Yufei Gu <[email protected]> wrote: >> > >> > >> > >> > +1 from me. >> > >> > Promoting the signer endpoint to the table level makes it more >> > >> > consistent with other table scoped APIs, and it cleanly provides the >> > >> > catalog(warehouse), namespace and table context without relying on >> > >> > provider specific properties. >> > >> > >> > >> > Yufei >> > >> > >> > >> > >> > >> > On Tue, Jan 20, 2026 at 12:08 PM Christian Thiel >> > >> > <[email protected]> wrote: >> > >> >> >> > >> >> +1 from me too, thanks Alex! >> > >> >> I tested returning the new Endpoint as the `s3.signer.endpoint` >> > >> >> config of a LoadTableResult against all Iceberg Releases from 1.6.1 >> > >> >> with Spark as well as pyiceberg 0.9 and 0.10 without problems. As >> > >> >> long as the behaviour of the Endpoint stays the same for S3, I don't >> > >> >> see any issues. >> > >> >> >> > >> >> On Tue, 20 Jan 2026 at 18:43, Jean-Baptiste Onofré >> > >> >> <[email protected]> wrote: >> > >> >>> >> > >> >>> +1 >> > >> >>> >> > >> >>> Regards >> > >> >>> JB >> > >> >>> >> > >> >>> On Fri, Jan 16, 2026 at 3:29 PM Alexandre Dutra <[email protected]> >> > >> >>> wrote: >> > >> >>>> >> > >> >>>> Hi all, >> > >> >>>> >> > >> >>>> We discussed remote signing last Wednesday during the catalog sync >> > >> >>>> meeting and we all agreed that the default signing endpoint [1] is >> > >> >>>> too >> > >> >>>> rigid. It lacks information about the table and namespace, but is >> > >> >>>> also >> > >> >>>> unaware of catalogs/warehouses, which can be challenging when the >> > >> >>>> same >> > >> >>>> signer client has to access multiple catalogs. >> > >> >>>> >> > >> >>>> One of the ideas that emerged was to promote the signer endpoint to >> > >> >>>> the "top-level" spec, under the table path. In short, it would >> > >> >>>> become >> > >> >>>> something like this: >> > >> >>>> >> > >> >>>> /v1/{prefix}/namespaces/{namespace}/tables/{table}/sign >> > >> >>>> >> > >> >>>> Promoting the endpoint makes it more aligned with similar ones, >> > >> >>>> like >> > >> >>>> the table credentials endpoint. It also solves the problem of >> > >> >>>> passing >> > >> >>>> the namespace, table and warehouse identifiers to the server. >> > >> >>>> >> > >> >>>> The endpoint would become provider-agnostic though. The current >> > >> >>>> endpoint structure appears to be sufficiently generic, showing no >> > >> >>>> S3-specific quirks. For example, implementing Azure support using >> > >> >>>> SAS >> > >> >>>> tokens seems feasible at first glance without any apparent >> > >> >>>> obstacles >> > >> >>>> (that I could think of). But there might be implications that I'm >> > >> >>>> not >> > >> >>>> immediately seeing. >> > >> >>>> >> > >> >>>> Of course, we would need to migrate the existing table properties >> > >> >>>> to >> > >> >>>> more neutral names, e.g.: >> > >> >>>> >> > >> >>>> s3.signer.uri -> signer.uri >> > >> >>>> s3.signer.endpoint -> signer.endpoint >> > >> >>>> >> > >> >>>> What are your thoughts on this idea? >> > >> >>>> >> > >> >>>> Thanks, >> > >> >>>> Alex >> > >> >>>> >> > >> >>>> [1]: >> > >> >>>> https://github.com/apache/iceberg/blob/55bfc7e82d03b5038bc5d0da852bd16615486926/aws/src/main/resources/s3-signer-open-api.yaml#L61
