Additional severity range applicable to logs with missing severity level

[Vincehood]

What are you trying to achieve?

Make it possible to map logs that lack severityText and severityValue values (which is, of course, not the wanted position) to have a more usable initial default mapping until some proper log processing/re-formatting is in place.
The OpenTelemetry spec hints at the usage of INFO level in these situations (see https://opentelemetry.io/docs/specs/otel/logs/data-model/#mapping-of-severitynumber) . From a usability perspective, associating an INFO level to a log with a message indicating a critical error is not the best option and may lead to wrong conclusions.

What did you expect to see?

The OpenTelemetry spec should include an "UNKNOWN" range associated to severityValue 0. This could be used to apply a more usable raw default mapping for logs missing a severity level.

[pellared]

I support this proposal. This is what we do in OTel Go:

• https://pkg.go.dev/go.opentelemetry.io/otel/log#Severity

I wouldn't be surprised if this is something that all languages are already doing.

[mx-psi]

Marking as ready with sponsor with @pellared as the sponsor per offline conversation

[pellared]

@Vincehood, do you want to contribute to the specification yourself?

I think that we can add explicitly 0 (usnet) value to the the table.

However, I am unsure if we need/want to change the sentence below given it is not normative and it just represents an optional interpretation.

Backend and UI may represent log records with missing severity information distinctly or may interpret log records with missing SeverityNumber and SeverityText fields as if the SeverityNumber was set equal to INFO (numeric value of 9).

[Vincehood]

Hi! Sounds great. My team mate @peffis already created a PR.
Thanks

[pellared]

The OpenTelemetry spec should include an "UNKNOWN" range associated to severityValue 0. This could be used to apply a more usable raw default mapping for logs missing a severity level.

@Vincehood, This looks is against the original intend of the Logs spec authors.
The authors also say that the intend was that 1..24 should be the only allowed values (and unset) from the API perspective.

Please see the discussion under #4509