►
From YouTube: 2021-09-07 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
D
D
A
D
D
If
you'd
like
to
do
it,
I'm
fine,
let's,
let's
go
ahead!
So
thanks,
everyone
for
joining
and
for
adding
stuff
to
the
agenda
who's.
First
with
the
persic.
A
Abbey
me
so
one
organization
tukhouse
has
come
to
us
with
interest
in
starting
a
pearl
sig,
and
I
know
from
a
prior
discussion
that
there
were
potentially
other
organizations
that
were
interested
in
pearl,
but
I
forget
who
they
are
and
I
would
like
to
connect
them
all
up
to
each
other
to
see
if
there's
enough
sustained
interest
to
actually
start
a
group.
A
D
A
E
Hi
I've
been
working
on
the
sampling
and
I
can
report
that
we
have
made
some
progress.
I
wasn't
prepared
to
give
a
summary
right
this
moment.
I'm
sorry,
we
have
two
oteps
open
number,
170
and
168.
170
has
more
approvals.
168
is
a
slightly
more
contentious
topic
about
how
we
do
propagation
because
of
the
long
weekend.
D
All
right
thanks,
so
you
said
on
thursdays:
would
it
make
sense
to
do
another
call
out
for
attendees
on
that?
One.
E
Yeah,
well,
I
think
that
what
we
actually
need
is
people
to
approve
these
oteps
they're
sitting
there
and
there
aren't
very
many
people
looking
at
them
and
it
does
take
sort
of
an
expert
understanding
to
kind
of
follow
this
stuff.
But
if
you've
done
propagation
for
open,
telemetry,
you're,
probably
gonna
understand
what
we're
trying
to
talk
about
here,
and
so
we
just
need
some
more
approvals.
E
That's
all.
I
have
right
now.
A
Yeah,
that's
for
me.
So
we've
started
several
instrumentation
meetings,
they're
on
the
calendar
right
now,
we'll
probably
we
currently
have
a
general
run.
That's
4
p.m.
Pacific
today
and
one
specifically
focused
on
messaging
semantics:
that's
8
am
on
thursdays
and
we'll
probably
start
a
third
meeting
or
workshop
to
focus
on
http,
specifically
just
to
get
that
one
over
the
finish
line.
A
Initial
meetings
have
been
good.
The
messaging
group
is
is
working
out
like
some
general
principles,
one
request
just
people
don't
necessarily
have
to
go
to
the
meetings,
but
we
are
looking
for
proposals
for
each
convention
type.
If
you
see
things
that
are
missing
or
things
you
don't
like
about
them,
so
just
a
general
call
out
that
group
is
happy
to
review.
A
You
know
spec
issues
and
prs,
so
it's
possible
to
contribute
asynchronously
and
one
perhaps
lower
bar.
We
have
a
lot
of
general
semantic
conventions
that
say
like,
for
example,
for
databases.
Here
are
some
general
conventions
for
databases
and
some
general
conventions
for
messaging,
and
then
we
have
a
lot
of
specific
service
types
like
for
databases,
you
have
mongodb
and
postgres
and
mariadb,
etc.
A
So
if
there
is
one
of
these
services
that
you
interact
with
and
know
about
a
simple
way
to
support
the
instrumentation
effort
would
just
be
to
make
a
pr
that
completes
explicitly
completes
the
table
for
that
service,
defining
all
of
the
general
conventions
how
they
map
and
if
some
of
them
are
not
applicable,
just
adding
a
row.
That's
explicitly
says
that
that'll
make
it
a
lot
easier
for
people
to
implement
those
conventions.
A
So
that's
just
one
call
out
for
for
requests
again.
You
don't
have
to
come
to
the
meetings.
This
is
just
some
work.
We're
asking
people
who
are
familiar
with
these
databases
to
to
do
ted.
Do
you
have.
A
Sure
so
it's
just
like,
if
you
go
into
the
spec,
I
will
show
you
real
quick,
so
it's
just
semantic
conventions
in
the
spec.
So
if
I
share
my
screen
real
quick
me
see.
A
Here's
more
generic
attributes,
for
example,
db
statement,
db,
operation,
etc,
etc,
and
then
we
get
into
specifics
for
each
type
like
for
cassandra.
Here
are
some
cassandra
specific
attributes.
However,
you
notice
there's
nothing
in
the
cassandra
section.
That
applies
how
db
statement,
for
example,
or
any
of
these
other
generic
database
attributes
should
be
filled
out
by
a
cassandra
client.
A
So
those
that's
basically
a
point
of
confusion,
so
we
extend
the
generic
attributes
for
cassandra
with
cassandra
specific
stuff,
but
we
don't
explain
how
cassandra
clients
should
fill
out
the
general
ones
so
this
table.
The
request
is
just
to
get
these
tables
for
each
one
of
these
types
to
be
filled
out
and
actually
we've
got
cassandra
filled
out,
but
then,
beyond
that,
we
just
have
examples,
for
example
in
mysql
there
is
an
example
for
how
it
should
be
filled
out,
but
it's
not
actually
defined
as
like
a
proper
table
in
the
semantic
conventions.
A
Yeah,
so
we
just
it's
like
this
stuff-
is
just
a
little
fuzzy
right
now,
and
it
would
be
great
just
to
make
it
absolutely
clear
for
all
of
these
common
types
that
we're
currently
listing
if
people
want
to
add
more,
for
example,
postgres,
isn't
in
here,
there's
there's
a
lot
of
a
lot
of
different
database
types
that
we
list
here,
but
don't
really
define
anything
for
so
it'll
make
this
area
long,
but
I
think
being
explicit
for
each
type.
How
it
should
be
applied
would
be
helpful
for
people.
A
Okay
and
that's
all
I
got
for
instrumentation,
I.
F
I
have
two
questions
that
I
put
in
the
meeting
notes.
So
first,
is
there
like
a
roadmap
or
the
timeline?
Do
we
plan
to
have
the
initial
release
at
some
point.
D
A
No,
I
don't
I
do
there.
Isn't
there
isn't
currently
a
timeline?
The
roadmap
is
simply
at
this
point
to
to
start
having
convention
specific
meetings
with
subject
matter
experts
and
then
trying
to
get
these
conventions
updated.
As
those
subject
matter,
experts
review
it,
but
this
is
a
very
fractured
project.
A
I
don't
think
we're
not
making
any
like
broad
changes
to
how
semantic
conventions
work
in
general,
it's
just
for
each
convention
type.
We
need
it
to
be
reviewed
and
filled
out,
in
particular
beyond
just
updating
or
expanding
and
reviewing
the
attributes
that
we
propose.
A
In
some
cases
we
feel
like
we
need
to
add
details
about
span
structure,
for
example
in
http.
How
do
you
define
a
logical,
http
request
versus
physical
http
requests?
It
might
make
up
that
one
logical
request
stuff
like
that,
so
we're
taking
a
very
piecemeal
approach.
A
So
I
don't
think
this
is
a
project
that
has
like
one
big
concrete
due
date.
If
that
makes
sense,.
F
F
It
might
have
a
dependency
on
the
trace
contacts
for
amqp
mqtt,
and
that
part,
my
understanding
is
currently
not
a
recommended
version
in
in
the
in
the
trace
contacts.
Spec,
though,
do
you
see
a
dependency
or
the
semantic
convention
wall
will
just
move
ahead,
assuming
that
the
propagation
part
will
cover
by
another
spec.
A
I
think
well
again,
these
are
all
I
think
these
are
all
individual
items
that
can
be
added
to
the
spec,
but
definitely
you
bring
up
a
good
point.
We
don't
explicitly
define
for
protocols
that
aren't
http,
we
don't
explicitly
define
where
the
propagation
headers
should
be
written
and
how
they're
written
right.
You
know,
it's
just
implicitly
assumed
you
should
stuff
this
into
say
the
you
know:
kafka
metadata,
for
example,
but
yes,
we
do
need
to
explicitly
define
these
things
so
that
you
know
various
clients.
A
Receivers
can
agree
on
where
to
look
for
this
stuff.
I
suppose
that
should
go
into
semantic
conventions,
I'm
not
really
sure.
Actually,
I
think
that
would
possibly
go
into
the
propagator
section
of
the
spec
and
maybe
extend
the
propagators
section
of
the
spec
to
explicitly
talk
about
how
propagators
should
be
applied
to
different
protocols,
since
those
aren't
really
conventions.
Conventions
are
about
the
data,
but
but
that's
that's
absolutely
sounds
like
something
we
need
to
do
because
it's
not
currently
in
the
spec.
D
C
That
would
only
cover
trace
context
propagation,
though
right
and
we
support
several
other
propagation
types.
So
I
I
think
we
should
still
specify
if
you're
going
to
use
a
text
map
propagator
with
kafka
or
activemq
or
any
other
protocol.
Here's
where
we
recommend
you
put
the
the
the
headers
that
are
produced
by
the
propagator.
C
The
pro
the
propagators
already
provide
that
right,
they
already
provide
a
fields
method
that
should
tell
you
what
keys
they
produce
or
expect
to
consume.
I
think
what
we
would
need
to
specify
is:
what
is
the
transport
mechanism
for
that
propagation?
Is
it
the
the
kafka
message?
Headers?
Is
it
you
know
active
mq?
What
mechanism
does
it
have
for
transporting
them?
If
we're
going
to
do
it
and
smtp?
Does
it
go
in
the
smtp
headers.
A
Yeah,
it
seems
a
little
I
mean
it
seems
like
a
kind
of
a
fuzzy
ground.
It
does
seem
a
little
weird
for
the
w3c
to
be
defining
those
things,
since
it's
outside
the
bounds
of
http
and
other
things.
As
far
as
I'm
aware
that
the
w3c
covers,
I
mean
it
makes
sense
that
the
trace
context
group
would
think
about
that
there,
but
yeah
like
what
anthony
says
we
need.
A
Ideally,
we
have
a
generic
description
for
where
these
things
go,
that
any
trace
context
headers
could
be
applied
to,
though,
obviously
we
don't
want
to
be
across
purposes
with
the
w3c
like
if
they're
going
to
issue
a
definition
for
for
how
this
stuff
works,
and
actually
I
have
questions
beyond
that
about
things
like
internet
of
things
and
protocols
that
are
extremely
lightweight
where,
where
our
trace
header
is
going
to
be
defined
for
for
those
protocols,
so
maybe
that's
that's
something
that
we
should.
We
should
hash
out
as
a
larger
community.
A
G
G
This
is
for
specifying
what
transport
to
use
with
otlp
like
jrpc,
okay,
you
know
http
and
so
on.
There
was
some
long
discussion
now
it
has
enough
reviews
to
be
merged,
but
I
think
it's
very
important
for
people
to
review
that
before
it
actually
lands.
So
please
take
a
look
at
that.
Likewise,
we
really
need
to
start
working
at
the
same
time
on
a
configuration
solution.
G
We
don't
want
to
have
an
explosion
of
environment
variables
and
bogdan
already
is
working
on
something,
but
if
you
can
actually
ask
your
manager
or
somebody,
your
team
is
interested
in
this.
It
would
be
nice
to
actually
gather
more
people,
because
I
think
we
will
be
needing
a
lot
of
work
there
and
that's
all
from
my
site.
A
Yeah
is
there
anyone
on
this
call
who
has
time
to
help
work
on
configuration,
because
I
agree:
we're
gonna
we're
going
to
get
buried,
we're
getting
buried
in
environment
variables
right
now
and
we're
continuing
to
approve
them,
because
we
don't
want
to
to
block
progress.
But
it's
it's
feeling
terrible
at
this
point
to
continue
approving
more
of
these
configuration
options
without
a
clear
design
for
how
configuration
in
general
should
be
applied
to
open
telemetry.
A
Personally,
it
feels
like
we're
having
gone
through
this
several
times
with
prior
projects
that
took
this
approach
of
just
kind
of
adding
environment
variables
or
adding
configuration
like
this.
You
end
up
having
a
huge
headache
later,
as
you
start,
exposing
more
and
more
functionality
that
needs
to
be
configured
because
the
convention,
the
configuration
you
added
earlier,
doesn't
actu
actually
ends
up
blocking
the
ability
to
expose
certain
options
later
minor
example,
but
we're
adding
things
to
expose
how
to
configure
otlp
via
environment
variable,
which
is
fine.
We
definitely
need
that.
A
It's
annoying
not
to
have
it,
but
it's
also
possible
to
add
multiple
otlp
exporters.
A
Since
otlp
exporters
are
defined
as
separate
exporters,
you
could,
in
theory
have
say
a
json
exporter
and
a
protobuf
exporter
installed
and
want
them
configured
differently
and
the
environment
variables
we're
adding
right
now
presume
you
only
have
one
installed
and
if
we
try
to
add
environment
variables
so
that
you
install
multiple
different
ones,
then
it
quote
looks
looks
ugly
because
we're
adding
way
more
environment
variables
than
we
would
add
if
you
could
just
configure
one.
A
So
that's
an
example
of
something
where
something
looks
clean
today,
but
actually
doesn't
match
our
architecture
and
in
the
future,
is
going
to
create
a
tricky
situation
for
figuring
out
how
we
would
expose
this
kind
of
functionality
as
we
start
making
it
real
and
open
telemetry.
A
So
I
just
want
to
flag
that
I've
been
down
this
path
several
times
on
other
large
projects,
and
it
ends
up
creating
a
lot
of
confusion
to
the
end
users,
when
this
stuff
isn't
isn't
clean
or
structured
or
follows
some
kind
of
consistent
pattern.
A
A
So
if
people
have
some
cycles
to
to
work
on
this,
I
do
think
it's
important
that
we
we
try
to
jam
something
out
quickly
here,
so
that
we
can
continue
to
accept
environment
variables
and
and
other
configuration
options,
but
do
so
in
the
framework
of
some
kind
of
design
that
we're
currently
missing.
B
Ted,
do
you
have
any
links
or
just
names
of
places
where
people
got
it
right
for.
A
Configuration
I
can,
I
can
like
draft
a
short
description.
I
don't,
I
would
say,
the
the
when
I've
seen
it
get
right.
It
has
a
couple
of
properties.
One
is
that
what
you
can
define
in
a
configuration
file
maps
exactly
to
what
you
can
define
in
environment
variables?
A
It's
not
that
you
have
to
expose
every
single
option
as
an
environment
variable,
but
there
needs
to
be
a
one-to-one
mapping
between
what
you
can
define
in
a
config
file
what
you
can
define
in
mvar,
because
that
allows
operators
and
people
who
have
access
to
environment
variables
to
be
able
to
override
what
gets
involved
what's
defined
in
a
config
file
and
if
those
two
things
don't
align
with
each
other.
If
you're
like
yeah.
Well,
we
just
want
to
expose
some
stuff
or
a
simpler
version
through
environment
variables.
A
It
makes
it
confusing
to
them,
because
there
are
now
all
these
interaction
rules
they
have
to
understand,
and
that
makes
and
then
the
side
effect
is
also
that
operators
can't
necessarily
override
or
or
clearly
interact
with
with
configuration
files,
so
that
makes
that
makes
stuff
really
really
hellish
for
end
users,
especially
people
once
you
get
into
more
complex
real
world
scenarios
where
you're
you're
really
trying
to
use
this
stuff
in
anger.
A
The
other
thing
that
I've
seen
helpful
is
to
prevent
painting
yourself
into
a
corner
as
because,
when
you
start
you're
not
going
to
define
everything
under
the
sun
and
that's
to
have
the
way
these
configurations
are
laid
out
to
match
the
the
architecture
that
they're
targeting.
A
So,
for
example,
we
have
an
sdk
that
has
various
plugins.
You
can
often
install
a
list
of
plugins
for
each
plugin
type,
like
exporters
and
span
processors,
etc.
A
So,
just
by
ensuring
that
the
the
configuration
file
is
laid
out
to
map
that
architecture
provides
like
a
pretty
good
guidance
for
ensuring
that,
as
you
continue
to
add
features,
you're
not
going
to
look
at
how
you
laid
out
your
configuration
and
go.
A
Oh
that
doesn't
that
doesn't
work
one
example
here
being
you
know,
otlp
right
like
we
have
multiple
otop
exporters.
So,
however,
the
configuration
for
ultrop
is
defined.
It
should
be.
You
know,
one
configuration
per
exporter
type,
probably
maybe
we
also
offer
some
simpler
path,
but
but
having
that
baseline
of
like
some
repeated
pattern
we
can
follow,
helps
and
then
for
environment
variables.
A
You
know
the
name
of
the
environment
variable
could
be
automatically
inferred
from
the
the
the
key
path
in
the
comp
file.
So
so
I
can.
A
I
can
write
this
up
in
a
thing
and
propose
it
to
to
help
with
that
part,
but
I
have
found
on
projects
we
do
what
we're
doing
now,
which
is
we
get
halfway
into
the
swamp
and
then
realize
that
we
need
to
apply
some
structure
and
then
we
do
apply
some
structure,
and
then
we
realize
we've
defined
a
bunch
of
stuff
that
doesn't
doesn't
match
any
structure,
because
you
know
we
didn't
have
the
structure
when
we
defined
it.
So.
B
Yeah,
I
I
gotcha
that'd
be
really
helpful
if
you
could
write
something
up.
I
can't
commit
100
to
this,
but
it's
been
a
pain
point
in
the
gosig
as
well,
that
we've
had
a
lot
of
feedback
from
users
that
are
saying,
like
we've
implemented
configuration
for
the
sdk
like
20
different
times,
and
so
like
it'd,
be
really
nice.
If
open
telemetry
just
did
something
like
this
yeah.
D
B
A
It's
great,
I
can
definitely.
I
can
definitely
help
push
this
along
yeah.
Just
my
request
is
that
that
other
people
participate
in
that
process.
I
know
we're
super
busy
with
a
lot
of
things,
but
this
just
feels
like
one
of
those
practicalities
that
the
the
longer
it
waits
the
the
the
weirder
it's
gonna
get
basically.
B
I
agree.
I
also
think
it's
going
to
pay
dividends.
If
you're
going
to
have
configurations
it's
going
to
be
across
languages
like
you're
saying
it
could
be
really
useful.
I
think
there's
also
some
issues.
We
need
to
address
on
like
priority
that
you
kind
of
brought
up
in
there
where
you
have
environment
variables,
override
a
configuration.
B
Currently,
I
think
the
specifications
written
where
anything
that's
in
the
code
is
the
top
priority,
which
is
kind
of
like
the
opposite.
What
you
said,
like
an
operator
can't
override
that
so,
like
that's,
gonna,
be
a
problem
yeah,
so.
A
I
get
the
impression
the
java
agent
group
is
driving
a
lot
of
configuration
environment
variable
things
which
is
great
because
they're,
you
know
they're
fast
and
they're
they're
farther,
along
than
everyone
else,
and
since
it's
a
an
agent,
you
know,
environment
variables
are
really
useful,
but
I
have
noticed
that,
because
that
agent
makes
some
assumptions
right,
it
doesn't
expose
everything
that
you
could
do
in
the
sdk
and
because
other
languages
use
other
mechanisms
right
like
this
came
up
in
a
prior
call
that
ruby.
You
know
it's
like.
A
Whatever
packages
you
have
installed
or
ruby
gems,
you
have
available.
Those
are
the
ones
you
get.
So
I
think,
there's
it's
not
that
what
what
the
java
people
are
proposing
is
like
wrong
in
some
general
sense
or
or
ugly,
but
because
that
agent
works
maybe
a
little
bit
different
than
how
the
sdks
work
in
other
languages
again
not
having
a
framework
makes
it
just
a
little
bit
difficult
to
have
those
discussions
because
they
aren't
they're
grounded
and
it
feels
just
like
people
throwing
opinions
around.
And
you
know
it's
like
not
fun.
A
Cool
okay,
well
I'll
I'll,
make
a
proposal.
I
guess
as
a
google
doc
and
or
maybe
even
go
all
the
way
to
adding
it
as
a
an
otep
but
yeah
having
having
a
review
guru
on
that
would
be
very
helpful.
Just.
A
I
feel
I
feel
some
pain
in
telling
people
to
slow
down
right.
I
would
say
if
people
are
frivolously
proposing
environment
variables
and
configuration
options,
then
yes
slow
down,
but
I
don't
generally
get
the
impression
people
are
doing
that
for
fun.
Usually,
if
someone's
proposing
one
of
these
things,
it's
because
they
need
it
or
they
have
a
user.
That's
requested
it
right.
This
is
kind
of
like
request.
A
Driven
proposals
is
my
impression,
and
so
it
feels
kind
of
bad
to
turn
around
and
say:
hey
we're
we're
putting
a
freeze
on
new
environment
variables
right
now,
unless
we're
actively
developing
a
solution,
that's
going
to
unblock
that
freeze,
and
so
it's
almost
like,
I
would
say
this
is
on
us
to
move
fast
and
get
a
proposal
in
place
before
more
environment
variables
get
proposed
and
submitted
like.
I
would
almost
want
to
say,
like
that's,
that's
the
clock.
We're
working
against
is
to
to
to
motivate
ourselves
to
get
this
done
quickly.
A
I
would
almost
say
like
we.
We
should
not
put
any
kind
of
freeze
until
we've
gotten
this
configuration
project
to
the
point
that
you
know
it
seems
like
it's
it's
imminent.
If,
if
we're,
if
we've
got
a
proposal-
and
it's
we're
just
hashing
out
the
final
pieces,
we're
about
to
add
it
to
the
spec,
then
then
saying
hang
on.
We
need
to
to
make
this
work
with.
This
spec
would
make
sense,
but
until
we
have
that,
I
think
we're
just
blocking
people
and
not
not
providing
a
solution
so,
and
I
don't
like
that.
F
A
I
think
security
concerns
that
I
mean,
I
think,
that's
a
little
bit
separate
from
what
we're
talking
about
right
now,
we're
talking
about
configuration,
design
and
we're
talking
about
design
and
layout.
I
feel
like
security
concerns,
are
kind
of
a
option
by
option
review
right,
like
I
don't
see
how
we
could
apply
a
general
design
principle
to
to
solving
those
problems.
F
F
So
you
can
enable
that
with
one
line
or
include
included
modules,
saying
I
want
environment
variable,
but
people
who
require
higher
security,
they
don't
want
any
environment
variable
at
all.
We
can
obtain
or
there's
a
like
opposite
design.
You
have
all
the
variables
by
default
and
you
have
an
option
to
say:
I
don't
want
any
environment
variable
just
for
security.
I
see.
F
H
Yeah,
just
you
know,
fyi
and
java.
We
all
we
have
all
of
our
configuration
all
of
our
non-programmatic
configurations
in
a
separate
module
that
is
still
marked
as
unstable,
because
all
of
this
is
still
kind
of
not
stable.
So
this
is
something
if
people
want
automatic
configuration
via
whatever
mechanism,
they
have
to
add
it
explicitly.
A
Awesome
but
yeah,
I
think
we
should
move
fast
on
these
things
riley.
That
is
a
great
example
of
that
should
be
worked
into
design.
You
know,
should
this
be
on
by
default
off
by
default,
but
in
general,
once
once
we
add
environment
variables,
yeah
they
are
stuck.
That
is
the
other
thing
I
would
say
from
reality
is
like
you,
you
cannot
break
those
once
once
you
add
them
in
general,.
H
Yeah
one
thing
we've
been
doing
in
java
also
is
people
are
requesting
environment
variables
that
haven't
been
specced
yet?
Is
we
put
them
under
a
separate
experimental
namespace
with
the
word
experimental
in
them?
So
it
is
very
clear
that
if
people
use
them
we're
going
to
break
them,
absolutely
we
will
break
them
and
it's
something
to
try
out,
but
not
a
not
a.
A
Guaranteed
future
video
good!
Good
luck!
Good
luck!
John!
Getting
out
from
under
that
that
that
it
feels
like,
like
the
the
x
dash
headers
from
http,
everyone
got
stuck
got
stuck
using
those
headers
forever,
but.
A
I
think
it's
just
it's.
Just
people
start
using
this
stuff
in
production
you
know,
and
and
when
it
breaks.
When
those
things
break
it's
it's
usually
it
breaks
at
deployment
time,
and
then
people
are
just
really
mad
when
that
happens,
so
so
just
just
fyi.
I
found
it
very
hard
to
to
take
those
things
back,
no
matter
what
morning
label
I
put
on
them
at
least
organizational
pressure
always
shows
up
to
to
say
no,
you
got
to
make
it
work,
we're
an
open
source
project.
So
maybe
it's
a
little
bit
different,
but.
H
A
Okay,
I
I
feel,
like
we've,
we've
talked
around
this
issue,
pretty
good.
I
don't
know
that
I
want
to
take
up
the
rest
of
time
on
it,
but
it
sounds
like
I
care
about
this,
so
so
I'm
gonna,
I'm
gonna,
help
drive
it.
D
H
All
right,
then,
next
up
yeah,
so
this
is
an
issue.
That's
been
opened
for
a
couple
months
that
I
would
love
eyes
on
the
core
issue
here.
Is
that
there's
a
request
to
build
a
propagator
that
has
different
extractors
than
injectors
in
order
to
basically
facilitate
conversion
from
something
legacy
to
w3c
trace
context,
and
they
only
want
to
emit
w3c,
but
they
want
to
accept
more
things,
and
so
the
question
is:
what
is
the
behavior
of
the
fields,
method
or
function
when
you're?
In
that
case?
Should
it
be
only
for
injectors?
H
Should
it
be
for
some
union
of
both
of
them?
It's
definitely
not
clear
in
the
specs.
So
would
love
some
eyes
on
that
and
some
clarity
so
that
we
can
get
the
java
pr
unblocked.
G
G
G
That's
correct
support,
jagger
yeah,
the
one
for
it's
an
interesting,
beat.
H
D
Okay,
thanks
and
I
have
one
more
pr
that
I
wanted
to
pinpoint
on
right
now,
so
that
one
is
about
http
request
and
response
headers
capturing
them.
The
current
speedo
state
of
the
pr
is
quite
fine.
I
think
it.
It
has
a
should
requirement
that
explicit
configuration
is
required.
So
you
just
don't
don't
capture
the
authorization
header
accidentally
and
and
send
it
to
your
jager
backend,
but
actually
that
it
needs
to
be
explicitly
put
into
an
allow
list
or
capture
list.