Clarify acceptable values for span status ERROR descriptions

[trask]

In particular, is it ok for instrumentation to populate span status ERROR description with exception.message or exception.type?

This is the current specification text:

When the status is set to Error by Instrumentation Libraries, the Description SHOULD be documented and predictable. The status code should only be set to Error according to the rules defined within the semantic conventions. For operations not covered by the semantic conventions, Instrumentation Libraries SHOULD publish their own conventions, including possible values of Description and what they mean.

Based on this, I would interpret both exception.message and exception.type as generally not ok in most cases (where the specific values depend on the application being instrumented and so cannot be listed out ahead of time by the instrumentation).

However, as @Oberon00 points out in #3198 (comment) and #3198 (comment), there are existing SDKs and Instrumentations which are populating the exception.message into the span status description, e.g.

• https://github.com/open-telemetry/opentelemetry-python/blob/v1.17.0/opentelemetry-sdk/src/opentelemetry/sdk/trace/__init__.py#L951
• https://github.com/open-telemetry/opentelemetry-dotnet/blob/fea6793a5590a18ff6d5e99460f9dfd8cf4c95b2/src/OpenTelemetry.Instrumentation.Http/Implementation/HttpHandlerDiagnosticListener.cs#L248

[trask]

One downside to including exception.message in span status description is that we've seen a couple of cases in Java instrumentation where exception.message (unfortunately) contains sensitive data:

• Lettuce instrumentation does not sanitize password in exception message  opentelemetry-java-instrumentation#8422
• PII data can be present in exception messages that are captured opentelemetry-java-instrumentation#3039

It may be a bit easier to explain to users that there's just one place (exception.message) where this shows up and that users may need to redact exception.message (which will likely be going to log pipeline in the future by default), as opposed to showing up in two places / signals.