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,21 @@ 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 be sometime after the HTTP response headers are read (or when they fail to be read).
+
+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 the span being ended 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.