Temporarily remove tracestate

The usage of the W3C `tracestate` for propagating OpenTelemetry-specific
data is currently ambiguous, and depends on some as yet unmade decisions
about how distributed context propagation.

In order to prevent breaking changes in the near-ish future, it feels
safest to temporarily remove `tracestate` from the spec so that its use
can be additive once these questions are resolved.

milestones.md

@@ -162,8 +162,7 @@ Example of scope for extended SDK:
 3. Discussions like
    1. Native (POJO) object vs. Proto-generated object with proto dependency in
       SDK
-4. Tracestate manipulation callbacks
-5. Other
+4. Other
 
 First iteration of SDK feedback – **mid August** we have specs, **End of
 August** – first iteration of Java SDK complete.

specification/api-tracing.md

@@ -194,9 +194,8 @@ propagated along side of a distributed context. `SpanContext`s are immutable.
 The OpenTelemetry `SpanContext` representation conforms to the [w3c TraceContext
 specification](https://www.w3.org/TR/trace-context/). It contains two
 identifiers - a `TraceId` and a `SpanId` - along with a set of common
-`TraceOptions` and system-specific `TraceState` values. `SpanContext` is
-represented as an interface, in order to be serializable into a wider variety of
-trace context wire formats. 
+`TraceOptions`. `SpanContext` is represented as an interface, in order to be
+serializable into a wider variety of trace context wire formats.
 
 `TraceId` A valid trace identifier is a 16-byte array with at least one
 non-zero byte.
@@ -208,17 +207,9 @@ byte.
 TraceOptions are present in all traces. Currently, the only TraceOption is a
 boolean `recorded`
 [flag](https://www.w3.org/TR/trace-context/#recorded-flag-00000001).
-
-`Tracestate` carries system-specific configuration data, represented as a list
-of key-value pairs. TraceState allows multiple tracing systems to participate in
-the same trace. 
-
 `IsValid` is a boolean flag which returns true if the SpanContext has a non-zero
 TraceID and a non-zero SpanID.
 
-Please review the W3C specification for details on the [Tracestate
-field](https://www.w3.org/TR/trace-context/#tracestate-field).
-
 ## Span
 
 A `Span` represents a single operation within a trace. Spans can be nested to

specification/overview.md

@@ -85,10 +85,6 @@ propagated from parent to child **Spans**.
   byte (bitmap).
   - Sampling bit -  Bit to represent whether trace is sampled or not (mask
     `0x1`).
-- **Tracestate** carries tracing-system specific context in a list of key value
-  pairs. **Tracestate** allows different vendors propagate additional
-  information and inter-operate with their legacy Id formats. For more details
-  see [this](https://w3c.github.io/trace-context/#tracestate-field).
 
 ### Links between spans
 

work_in_progress/specification/trace/LogCorrelation.md

@@ -36,9 +36,6 @@ The sampling bit of the current span, as a boolean.  See
 
 TODO(sebright): Include "samplingScore" once that field is added to the SpanContext.
 
-TODO(sebright): Add a section on fields from the Tracestate. Users should be able to add
-vendor-specific fields from the Tracestate to logs, using a callback mechanism.
-
 TODO(sebright): Consider adding parent span ID, to allow recreating the trace structure from logs.
 
 ## String format for tracing data