danielcweeks commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r3919301812
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2181,56 @@ components:
explode: false
example: "vended-credentials,remote-signing"
+ user-agent:
+ name: User-Agent
+ in: header
+ description: >
+ Recommended header for a client to identify itself to the catalog. It
+ follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
+ 5.5.3): a whitespace-separated list of `product/version` tokens,
+ optionally followed by a parenthesized comment.
+
+
+ Tokens SHOULD be ordered from the outermost component to the innermost,
+ so the most specific caller appears first: the engine or application,
+ then any integration or connector, then the Iceberg client library,
+ then the language runtime. The Iceberg client library token is the one
+ component every client can supply and SHOULD always be present.
+ Recommended library tokens are `iceberg-java`, `pyiceberg`,
+ `iceberg-rust`, and `iceberg-go`.
+
+
+ The trailing parenthesized comment is an open extension point for
+ additional, lower-value context such as build identifiers, the HTTP
+ library, or the operating system, given as bare tokens or `key=value`
+ pairs separated by `; `. Servers SHOULD treat the comment as free-form
+ and MUST NOT depend on its contents.
+
+
+ Examples:
+
+
+ `pyiceberg/0.11.0 (cpython/3.11.4)` — a client library used directly.
+
+
+ `Trino/438 iceberg-java/1.9.0 (jvm/17.0.9)` — an engine embedding the
+ Iceberg Java library.
+
+
+ `Spark/4.0.0 iceberg-spark/1.9.0 iceberg-java/1.9.0 (scala/2.13.16)` —
+ an engine with a connector layer on top of the library.
+
+
+ This header is optional and informational; see "Client Identification"
+ in the API description for the rules that apply to all client-identity
+ headers. Servers MUST NOT reject a request based on its presence,
Review Comment:
> Servers MUST NOT reject . . .
I don't agree with this statement. Not because I'm concerned that
implementations would gate maliciously, but rather there may be versions that
have critical bugs or vulnerabilities and the catalog should be able to reject
certain operations for those clients.
For example, if we know a specific version of engine or library will produce
corrupt statistics, we should be able to reject commits by those clients.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
