Reconsider `tls-implementation-name` and `tls-implementation-version`

[omasanori]

tls-implementation-name and tls-implementation-version might be useful for debugging but I doubt they should be part of the API. Instead, for instance, tls.implementation-name and tls.implementation-version (or just tls.name and tls.version) version flags would provide similar benefit.

[lassik]

tls-implementation-name and tls-implementation-version might be useful for debugging but I doubt they should be part of the API.

Would they cause harm of some kind?

Instead, for instance, tls.implementation-name and tls.implementation-version (or just tls.name and tls.version) version flags would provide similar benefit.

Sounds reasonable. The latest release of Gauche has this:

$ gosh -V | grep tls
(gauche.net.tls mbedtls)

but does not say the version number.

[omasanori]

Would they cause harm of some kind?

Not much. Rather, I am against these procedures since they are implementation details that is irrelevant with the usage. Providing them is similar to providing a procedures to detect the version of BLAS or Eigen in Array SRFIs, or doing such to detect the version of the underlying JSON library in SRFI 180.

User code parsing these information and change its behavior based on the result would be actual harm, as it will essentially probing implementation to detect features, like the User-Agent HTTP field. Such code is not robust against the libraries' changes.

While writing such code is still possible even with version flags, providing dedicated procedures to provide the information may indicate that such code is supported.