…received

This is considered an bug in the spec that was uncovered in the discussion here:
open-telemetry#442 (comment)

I did some spelunking and the "generate" recommendation comes from the very first commit:
open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc
where they were copied from Java repo, to which they were copied from OpenCensus
open-telemetry/opentelemetry-java#134 and in OpenCensus the
wording first time appeared here census-instrumentation/opencensus-proto#160
(authored by @SergeyKanzhelev, merged by @bogdandrutu).

We are deleting the requirement to generate a new trace id or span id if an invalid
id is received. The receivers can decide how they want to treat the invalid id (just
like upon receiving any other invalid id), e.g. they may drop it, log an error, accept
the invalid data, etc. We are not going to prescribe a particular receiver behavior
when invalid trace/span id is received.

…received (#444)

This is considered an bug in the spec that was uncovered in the discussion here:
#442 (comment)

I did some spelunking and the "generate" recommendation comes from the very first commit:
b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc
where they were copied from Java repo, to which they were copied from OpenCensus
open-telemetry/opentelemetry-java#134 and in OpenCensus the
wording first time appeared here census-instrumentation/opencensus-proto#160
(authored by @SergeyKanzhelev, merged by @bogdandrutu).

We are deleting the requirement to generate a new trace id or span id if an invalid
id is received. The receivers can decide how they want to treat the invalid id (just
like upon receiving any other invalid id), e.g. they may drop it, log an error, accept
the invalid data, etc. We are not going to prescribe a particular receiver behavior
when invalid trace/span id is received.

…received (open-telemetry#444)

This is considered an bug in the spec that was uncovered in the discussion here:
open-telemetry#442 (comment)

I did some spelunking and the "generate" recommendation comes from the very first commit:
open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc
where they were copied from Java repo, to which they were copied from OpenCensus
open-telemetry/opentelemetry-java#134 and in OpenCensus the
wording first time appeared here census-instrumentation/opencensus-proto#160
(authored by @SergeyKanzhelev, merged by @bogdandrutu).

We are deleting the requirement to generate a new trace id or span id if an invalid
id is received. The receivers can decide how they want to treat the invalid id (just
like upon receiving any other invalid id), e.g. they may drop it, log an error, accept
the invalid data, etc. We are not going to prescribe a particular receiver behavior
when invalid trace/span id is received.

…received (open-telemetry#444)

This is considered an bug in the spec that was uncovered in the discussion here:
open-telemetry#442 (comment)

I did some spelunking and the "generate" recommendation comes from the very first commit:
open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc
where they were copied from Java repo, to which they were copied from OpenCensus
open-telemetry/opentelemetry-java#134 and in OpenCensus the
wording first time appeared here census-instrumentation/opencensus-proto#160
(authored by @SergeyKanzhelev, merged by @bogdandrutu).

We are deleting the requirement to generate a new trace id or span id if an invalid
id is received. The receivers can decide how they want to treat the invalid id (just
like upon receiving any other invalid id), e.g. they may drop it, log an error, accept
the invalid data, etc. We are not going to prescribe a particular receiver behavior
when invalid trace/span id is received.

…received (open-telemetry#444)

This is considered an bug in the spec that was uncovered in the discussion here:
open-telemetry#442 (comment)

I did some spelunking and the "generate" recommendation comes from the very first commit:
open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc
where they were copied from Java repo, to which they were copied from OpenCensus
open-telemetry/opentelemetry-java#134 and in OpenCensus the
wording first time appeared here census-instrumentation/opencensus-proto#160
(authored by @SergeyKanzhelev, merged by @bogdandrutu).

We are deleting the requirement to generate a new trace id or span id if an invalid
id is received. The receivers can decide how they want to treat the invalid id (just
like upon receiving any other invalid id), e.g. they may drop it, log an error, accept
the invalid data, etc. We are not going to prescribe a particular receiver behavior
when invalid trace/span id is received.

…received (open-telemetry#444)

This is considered an bug in the spec that was uncovered in the discussion here:
open-telemetry#442 (comment)

I did some spelunking and the "generate" recommendation comes from the very first commit:
open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc
where they were copied from Java repo, to which they were copied from OpenCensus
open-telemetry/opentelemetry-java#134 and in OpenCensus the
wording first time appeared here census-instrumentation/opencensus-proto#160
(authored by @SergeyKanzhelev, merged by @bogdandrutu).

We are deleting the requirement to generate a new trace id or span id if an invalid
id is received. The receivers can decide how they want to treat the invalid id (just
like upon receiving any other invalid id), e.g. they may drop it, log an error, accept
the invalid data, etc. We are not going to prescribe a particular receiver behavior
when invalid trace/span id is received.