span exporter concurrency: expand on Export() requirements

specification/trace/sdk.md

@@ -614,16 +614,22 @@ Protocol exporters that will implement this
 function are typically expected to serialize and transmit the data to the
 destination.
 
-Export() will never be called concurrently for the same exporter instance.
-Export() can be called again only after the current call returns.
+By default Export() will never be called concurrently for the same exporter
+instance and can be called again only after the current call returns. This does
+not mean Export() is required to block until the batch is successfully sent.
+What Export() does before returning is language and exporter dependent. However,
+the implementation MUST document the concurrency characteristics the SDK
+requires of the exporter.
 
 Export() MUST NOT block indefinitely, there MUST be a reasonable upper limit
 after which the call must time out with an error result (`Failure`).
 
-Any retry logic that is required by the exporter is the responsibility
-of the exporter. The default SDK SHOULD NOT implement retry logic, as
-the required logic is likely to depend heavily on the specific protocol
-and backend the spans are being sent to.
+Concurrent requests and retry logic is the responsibility of the exporter. The
+default SDK's Span Processors SHOULD NOT implement retry logic, as the required
+logic is likely to depend heavily on the specific protocol and backend the spans
+are being sent to. For example, the [OpenTelemetry Protocol (OTLP)
+specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md)
+defines logic for both sending concurrent requests and retrying requests.
 
 **Parameters:**
 
@@ -635,11 +641,10 @@ e.g. for spans in Java it will be typically `Collection<SpanData>`.
 
 ExportResult is one of:
 
-* `Success` - The batch has been successfully exported.
-  For protocol exporters this typically means that the data is sent over
-  the wire and delivered to the destination server.
-* `Failure` - exporting failed. The batch must be dropped. For example, this
-  can happen when the batch contains bad data and cannot be serialized.
+* `Success` - The batch has been successfully passed to the Exporter.
+* `Failure` - The Exporter failed to accept the batch. The batch must be
+  dropped. For example, this can happen when the batch contains bad data and
+  cannot be serialized.
 
 Note: this result may be returned via an async mechanism or a callback, if that
 is idiomatic for the language implementation.