Christian Neumüller

@trask I wonder, how does auto-instr-java deal with that? It has a gRPC instrumentation, would that not cause a feedback loop with the OTLP exporter currently?

@sirzooro If you need propagation of the flag, you are probably looking for the existing sampled flag, not this feature.

Should we maybe wait a bit with this and do it together with IsRemote once https://github.com/open-telemetry/oteps/pull/182 is merged, to minimize the chance of inconsistencies?

Currently there is already a spec on what an HTTP app is in the semantic conventions, but no way to represent it, see https://github.com/open-telemetry/opentelemetry-specification/blob/4ab7c2fb4964c14fe972b03b5bb6825573bafb24/specification/data-http.md#http-server-definitions: > Within a single virtual host,...

Previous implementation: https://github.com/open-telemetry/opentelemetry-specification/pull/263/commits/93643578c22b8b35d581551ddb62575391011ec9 (`http.app` span attribute), https://github.com/open-telemetry/opentelemetry-specification/pull/263/commits/a8685ca058a464c95bf67c261627d231b55b070c (`http.app_root`).

Agree, I also had that thought when re-reading the spec quoted above. But I think that's a minor detail here.

The initial problem here is not that *service.name* in particular would imply process-level isolation, but that the *Resource* concept itself allows only one resource per process (technically per TracerProvider, but...

This might be solvable by https://github.com/open-telemetry/oteps/issues/78.

Isn't an unsampled but exported span an oxymoron? How could this happen in practice?

Do you really need this information? You can also create spans without attributes if you just need these spans for linking. Also note that rpc.* should be set to logical...