Clarify HTTP client duration

CHANGELOG.md

@@ -68,3 +68,5 @@ release.
   ([#13](https://github.com/open-telemetry/semantic-conventions/pull/13))
 - Clarify `process.runtime.jvm.threads.count` refers to platform threads.
   ([#54](https://github.com/open-telemetry/semantic-conventions/pull/54))
+- Clarify when HTTP client spans should end.
+  ([#70](https://github.com/open-telemetry/semantic-conventions/pull/70))

specification/trace/semantic_conventions/http.md

@@ -194,6 +194,30 @@ Following attributes MUST be provided **at span creation time** (when provided a
 
 Note that in some cases host and port identifiers in the `Host` header might be different from the `server.address` and `server.port`, in this case instrumentation MAY populate `Host` header on `http.request.header.host` attribute even if it's not enabled by user.
 
+### HTTP client span duration
+
+HTTP client spans SHOULD start sometime before the first request byte is sent. This may or may not include connection time.
+
+HTTP client spans SHOULD end when the response body has been fully read or the response closes with an error.
+
+However, if there is any possibility for application code to not fully read the HTTP response
+(and for the HTTP client library to then have to clean up the HTTP response asynchronously),
+the HTTP client span MUST be ended earlier (e.g. after the HTTP response headers are read, or fail to be read).
+
+This avoids having to end the span asynchronously later on at a time which is no longer directly associated with the application code which made the HTTP request.
+
+Because of the potential for confusion around this, HTTP client library instrumentations SHOULD document their behavior around ending HTTP client spans.
+
+> **Note**
+> It is nice for HTTP client spans to represent the complete lifetime of the HTTP request.
+> An HTTP request ends once the response body has been fully read or the response closes with an error.
+> However, if there is any possibility for application code to not fully read the HTTP response
+> (and for the HTTP client library to then have to clean up the HTTP response asynchronously),
+> the HTTP client span SHOULD be ended earlier (e.g. after the HTTP response headers are read, or fail to be read).
+> This avoids having to end the span asynchronously later on at a time which is no longer directly associated with the application code which made the HTTP request.
+>
+> Because of the potential for confusion around this, HTTP client library instrumentations SHOULD document their behavior around ending HTTP client spans.
+
 ### HTTP request retries and redirects
 
 Retries and redirects cause more than one physical HTTP request to be sent.