add empty error reason

docs/http/http-metrics.md

@@ -90,7 +90,7 @@ SHOULD include the [application root](/docs/http/http-spans.md#http-server-defin
 **[2]:** Instrumentations SHOULD define and document a list of applicable error reasons that describe why request has failed or response was not received partially or fully. For example, request could be canceled, DNS resolution or TLS handshake may fail, or the connection maybe prematurely terminated before response is sent/received.
 Error reason values MUST be a closed set known at the development time of the instrumentation and MUST have low cardinality.
 
-**[3]:** If and only if request or response has ended prematurely.
+**[3]:** If request or response has ended prematurely. When missing, the value is assumed to be `empty`.
 
 **[4]:** HTTP request method value SHOULD be "known" to the instrumentation.
 By default, this convention defines "known" methods as the ones listed in [RFC9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-methods)
@@ -131,6 +131,7 @@ SHOULD NOT be set if only IP address is available and capturing name would requi
 
 | Value  | Description |
 |---|---|
+| `` | No error. Default value. |
 | `_OTHER` | Any error reason instrumentation does not define custom value for. |
 
 `http.request.method` has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.
@@ -249,7 +250,7 @@ SHOULD include the [application root](/docs/http/http-spans.md#http-server-defin
 **[2]:** Instrumentations SHOULD define and document a list of applicable error reasons that describe why request has failed or response was not received partially or fully. For example, request could be canceled, DNS resolution or TLS handshake may fail, or the connection maybe prematurely terminated before response is sent/received.
 Error reason values MUST be a closed set known at the development time of the instrumentation and MUST have low cardinality.
 
-**[3]:** If and only if request or response has ended prematurely.
+**[3]:** If request or response has ended prematurely. When missing, the value is assumed to be `empty`.
 
 **[4]:** HTTP request method value SHOULD be "known" to the instrumentation.
 By default, this convention defines "known" methods as the ones listed in [RFC9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-methods)
@@ -290,6 +291,7 @@ SHOULD NOT be set if only IP address is available and capturing name would requi
 
 | Value  | Description |
 |---|---|
+| `` | No error. Default value. |
 | `_OTHER` | Any error reason instrumentation does not define custom value for. |
 
 `http.request.method` has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.
@@ -339,7 +341,7 @@ SHOULD include the [application root](/docs/http/http-spans.md#http-server-defin
 **[2]:** Instrumentations SHOULD define and document a list of applicable error reasons that describe why request has failed or response was not received partially or fully. For example, request could be canceled, DNS resolution or TLS handshake may fail, or the connection maybe prematurely terminated before response is sent/received.
 Error reason values MUST be a closed set known at the development time of the instrumentation and MUST have low cardinality.
 
-**[3]:** If and only if request or response has ended prematurely.
+**[3]:** If request or response has ended prematurely. When missing, the value is assumed to be `empty`.
 
 **[4]:** HTTP request method value SHOULD be "known" to the instrumentation.
 By default, this convention defines "known" methods as the ones listed in [RFC9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-methods)
@@ -380,6 +382,7 @@ SHOULD NOT be set if only IP address is available and capturing name would requi
 
 | Value  | Description |
 |---|---|
+| `` | No error. Default value. |
 | `_OTHER` | Any error reason instrumentation does not define custom value for. |
 
 `http.request.method` has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

docs/http/http-spans.md

@@ -110,7 +110,7 @@ sections below.
 **[1]:** Instrumentations SHOULD define and document a list of applicable error reasons that describe why request has failed or response was not received partially or fully. For example, request could be canceled, DNS resolution or TLS handshake may fail, or the connection maybe prematurely terminated before response is sent/received.
 Error reason values MUST be a closed set known at the development time of the instrumentation and MUST have low cardinality.
 
-**[2]:** If and only if request or response has ended prematurely.
+**[2]:** If request or response has ended prematurely. When missing, the value is assumed to be `empty`.
 
 **[3]:** If and only if it's different than `http.request.method`.
 
@@ -142,6 +142,7 @@ Following attributes MUST be provided **at span creation time** (when provided a
 
 | Value  | Description |
 |---|---|
+| `` | No error. Default value. |
 | `_OTHER` | Any error reason instrumentation does not define custom value for. |
 
 `http.request.method` has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

model/http-common.yaml

@@ -68,11 +68,14 @@ groups:
         type:
           allow_custom_values: true
           members:
+            - id: empty
+              value: ""
+              brief: 'No error. Default value.'
             - id: other
               value: "_OTHER"
               brief: 'Any error reason instrumentation does not define custom value for.'
         requirement_level:
-          conditionally_required: If and only if request or response has ended prematurely.
+          conditionally_required: If request or response has ended prematurely. When missing, the value is assumed to be `empty`.
         examples: ['timeout', 'name_resolution_error', 'server_certificate_invalid']
         note: >
           Instrumentations SHOULD define and document a list of applicable error reasons that describe why request