►
From YouTube: 2020-07-28 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).
A
A
C
D
E
C
C
We're
about
to
get
this
show
underway.
C
C
Okay,
so
I've
put
the
time
box
of
two
agenda
items
at
the
top
of
the
meeting
in
order
to
go
over
our
issues
and
make
sure
they're
triaged
and
track
the
progress
of
where
they've
been
going.
So
this
is
something
I'd
like
to
carry
on
on
a
weekly
basis.
C
I'll
explain
a
little
bit
about
this
just
the
first
time,
this
set
of
stuff
a
set
of
steps
that
we're
going
to
go
through
the
next
next
seven
minutes
are
going
over
issues,
that's
newly
incoming
making
sure
they
got
the
required
labels,
whether
they've
got
the
release,
label
party
label
area,
spec
label,
sign
issues
and
then
assigning
them
that
are
required
for
ga,
so
this
stuff
can
actually
be
done
during
the
week.
We
don't
have
to
wait
till
the
specs
meeting
in
order
to
do
this
process.
This
is
just
a
double
check.
C
During
the
specific
beating
to
check.
What's
happened,
the
past
seven
days
could
be
a
you
know:
a
zero,
a
no
up.
The
second
part
is
to
check
to
get
updates
on
status
of
the
issues.
That's
already
been
assigned
and
get
a
tally
of
closed
issues
and
unfair
any
blockers
in
the
assignee
of
the
p1
issues
or
any
of
the
ones
for
the
ga
is
it's
the
duty
of
the
assignee
in
order
to
be
able
to
provide
this
status
when
called
upon.
So
that's
the
significance
of
being
assigned
something.
C
So,
let's
just
jump
right
into
it.
We
have
newly
opened
issues
since
last
segment
was
having
a
look
over
this.
I
think
there's
just
five
of
them
that
need
priority
since
the
past
seven
days.
So
I
stopped
at
here.
We've
got
required
for
jp2,
p2
p2,
so,
for
example,
adding
semantic
conventions.
C
C
Priority
yeah:
we
can
skip
that
required
future.
G
C
Okay,
okay,
so
let's
go
to
this
one!
This
one
requires
a
decision
on
whether
it's
required
for
ga
and
then
after
that,
a
party
if
necessary,.
G
I
think
liz
was
trying
to
have
this
done
this
week,
so
probably
pretty
high
priority,
but
I'm
not
liz.
I
don't
know.
G
Yeah
in
the
go
sig
there's
a
there's,
a
change,
that's
related
to
this,
and
she
was
working
on
that
yeah.
Okay,
should.
G
I
sounds
great
to
me:
I
I'm
not
the
right
person
to
ask
that,
but
I
guess
in
absence
I
think
that
makes
sense.
H
F
That
accurate
use,
no,
no,
don't
usually
don't
use
lease
use.
The
github
ldap
like
yeah
is
that
all
right
yeah,
you
don't
know
if
people
want
to
be
called
by
name
or
stuff.
C
Okay,
all
right
so
that
one
no
spec
for
http,
specific
metrics.
C
Probably,
and
this
one,
I
guess
looks
like
implicitly
required
for
ga
oops.
F
I
don't
know
if,
anyway,
we
need
to
make
a
decision
by
ge.
C
I
just
lost
track
there.
D
C
I
C
C
All
right,
good
job,
guys
that
clears
that
off.
C
That's
a
good
progress,
that's
progress,
yeah
and
we
also
close
a
bunch
of
them.
It
looks
like
some
of
these
need
assignments.
I
I
J
J
Yeah,
we
now
have
three
different
environment
variables
for
the
the
resource.
Some
languages
are
using
hotel
resource
labels,
others
are
using
hotel
resource
attributes
and
then
I
think
the
otap
just
calls
it
hotel.
C
Resource
should
this
be
assigned
to
james.
L
C
There
it
goes
okay,
rename
context
as
I'm
going
through
this.
You
guys
can.
If
anybody
one
of
these
owners
wants
to
move
it
over,
that
will
also
update
the
status.
Sorry,
let
me
clear
up
some
tabs.
C
M
M
That
was
our
impression
if
you
are
more
familiar
danielle,
maybe
you
can
give
us
some
more.
N
Yeah,
so
I'm
on
the
working
group
actually
so
is
matt
ware,
and
so,
with
the
with
the
recent
renamed
baggage.
I
think
we
have
decided
essentially
to
keep
it
more
or
less,
as
is
so.
We
we
renamed
the
the
header
to
baggage
and
we're
going
to
keep
the
current
value
format
which
actually
mimics
the
set
cookie
header,
and
we
are
fairly
confident
that
it
won't
change.
N
For
the
specification
I
mean,
as
an
official
recommendation
yep,
I
don't
all
you
know
that
the
processes
all
kind
of
take
time.
So
I
would
say
hopefully.
H
H
M
Okay,
oh
fair
enough,
yeah,
danielle
and
morgan.
Would
you
go
mad
where,
as
well,
would
you
mind
commenting
this
in
this
issue?
In
that
case,
we
can
move
forward.
Sure
yeah
I'll.
C
C
This
will
be
the
last
one
because
we're
hitting
up
against
the
time
limit,
trying
to
stop
at
the
21
minute.
I
need
assigning
for
this
one
resource
conventions,
compute
instances
versus
compute
unit.
H
F
I
C
Now,
okay,
so
bump
this
one
down
to
priority.
F
C
Okay,
I've
hit
time
we
can
go
over
continue.
C
C
F
And
then
does
it,
can
we
do
it
another
level
of
changing
the
the
area
like
picking
the
area
as
well
or
how
can
we
ask
users
to
pick
areas.
I
I
K
F
Andrew,
I
think
it
is
gone.
Let's
move
to
the
next
topics.
Sure,
okay,
perfect!
Thank
you.
So
the
next
topic
on
the
agenda
is
from
nikita.
O
Can
you
yeah,
I
just
I
just
wanted
to
bring
to
your
attention.
There
is
a
issue
about
limiting
the
amount
of
attributes
and
events
on
the
span.
I
just
added
to
that.
Do
we
want
to
limit
the
size
of
values
as
well
so
and
because
I
haven't
asked
for
that
from
my
from
my
employer,
so
I
just
if
you
want
to
do
that,
then.
O
O
F
If
it's
an
exporter
thing,
if
it's,
if
we
believe
that
that
is
a
vendor-specific
thing,
we
should
not
put
anything
if
we
believe
that
actually
this
is
something
that
we
want
to
limit
and
truncate
the
size
in
the
sdk.
So
before
hitting
the
the
outside
of
the
sdk,
then
we
should
have
a
spec
for
this.
So
now
I
don't
know
exactly
what
you
have
in
mind.
I
cannot
read
mind
yet,
but
I
will
work
on
this
in
the
meantime.
F
Try
to
to
to
better
understand
what
exactly
you
try
to
propose
or
try
to
to
like
think
about
what
you
exactly
want
to
propose
and
if
it's
in
the
sdk
you
should
file
an
issue
and
explain
the
motivation
of.
Why
do
we
need
it.
B
The
idea
is
to
have
some
html
tag
that
describes
which
table
should
be
print
and
the
tool
that
I
attached
to
this
pr
will
automatically
generate
the
markdown.
For
that.
So
please
have
a
look
of
a
review,
and
the
discussion
that
I
would
like
to
address
here
is,
I
also
add
the
code
that
generates
the
table
or.
E
F
How
do
we
consume
this
code?
Do
we
ask
people
manually
to
run
this
code?
Do
we
plan
to
use
github
actions
to
generate
this
after
every
pr
is
merged?
I
mean
yeah.
B
The
idea
currently
is
before
submit
or
committing
you
run
this
out
manually
like
it
is
currently
for
the
table
of
content.
Plugin.
F
Then
then,
then
I
will
propose
a
different
approach.
I
will
propose.
We
create
a
new
repo.
I
have
the
same
idea
for
other
tools.
I
would
propose
we
create
another
repo
called
docker
images
or
something
I
would
suggest
that
we
build
a
docker
container
instead
of
having
people
to
set
up
the
entire
python
environment
or
whatever
they
need,
they
just
do
a
docker
run.
F
A
This
is
alita.
I
had
a
question
on
that.
Usually
best
practice
on
the
open
source
on
an
open
source
project
is
to
have
a
builds.
You
know
repo,
which
is
then
has
different
kinds
of
images
it
could
docker
would
be
one
and
then
you
could
have
others
also
over
time.
Okay,.
F
A
Yes,
I
mean
we're
going
to
you're,
going
we're
going
to
distribute
the
build
scripts
right
for,
for
being
able
to
you
build
any
kind
of
an
environment
and
an
image.
F
Okay,
I
will
yeah
I'll
name
that
build
script
or
something
and
we'll
start
only
with
docker,
initially
sure
sure,
and
then
we
can
figure
out
if
we
need
linux
packages
or
other
packages
to
support.
F
Okay,
thanks
thanks
for
the
feedback
sure
next
item
so
giovanni.
I
will
put
this
on
me
too,
okay,
mitchell,
or
did
I
pronounce
it
correctly.
P
Yep,
that's
right
thanks
yeah!
So
this
we
brought
brought
this
issue
up
a
couple
specs
ago
for
the
adding
a
global
error
handler
to
the
sdk
there's
essentially,
but
there's
we
sort
of
implemented
the
poc
error
handler
in
java
and
there's
been
some
discussion
surrounding
that,
so
just
wanted
to
bring
it
to
the
table
again.
Basically,
I
think
that
or
I
think
that
there's
agreed
that
there
be
potentially
some
value
in
adding
like
a
customizable
global
arrow
handler
whenever
there
are
issues
handling
or
irredeemable
open,
telemetry
events.
P
So
maybe,
like
exporter
errors,
there
are
a
couple
of
other
things
and
I
think
by
default,
the
behavior
would
be
to
just
log
the
error.
But
I
think
that
I
want
to
open
that
up
to
a
couple
of
two
other
suggestions
as
well
and
like
talk
a
little
bit
about
what
exactly
we
want
here.
If
anything.
P
P
I
I
just
saying
that
I
think
that
the
like
overall
goal
is
to
be
able
to
like
easily
propagate
errors
to
the
user
in
case
that
there's
some
things
going
wrong,
that
their
data
isn't
getting
through.
M
F
I
was
mostly
surprised,
reading
this
issue,
that
we
are
an
observability
library
and
we
fall
back
to
the
fact
that
let
user
deal
with
the
observability
part
of
our
library
was
was
just.
I
was
just
surprised
that
we
are
trying
to
build
the
awesome,
observability
library
and
we
don't
know
how
to
observe
our
own
library.
F
F
All
the
things
to
the
user
and
user
decides
whatever
they
want
to
do
with
these
things,
and
also
I
found
that
there
are
two
categories
of
things:
there
are
transient
errors
like
fail
to
export
for,
once
or
twice
or
whatever,
or
fail
to
export
permanently
to
something
like
there
are
more
like
fatal
errors
where
we're
not
going
to
be
able
to
export
any
telemetry,
or
there
is
a
transient
error
that
the
back
end
that
I'm
using
for
exporting
this
telemetry
data
is
down
for
for
a
period
of
time,
but
nothing
to
worry
about
more
than
just
like.
F
It
happens
like
it's
softer,
so
I
I
don't
know
what
approach
we
want
to
to
go
with.
Personally,
I
think
I
think
what
we
should
do
is
to
to
produce
metrics
on
our
side
and
traces
where
possible,
and
only
for
fatal
errors.
F
We
should
let
the
user
decide
if
they
want
to
crash,
because
we
believe
without
telemetry
they
cannot
run
the
software
or
they
want
to
do
other
things
because,
for
example,
the
absurd
on
this
is,
if
we
send
the
user
back,
the
the
the
fatal
error
or
something,
and
if
they
log,
but
they
use
our
in
the
future,
they
will
lose
our
use.
Our
logging
part
of
the
library
or
they
will
use
some
of
the
logging
support
that
we
offer.
M
G
In
in
the
in
the
go
world,
we've
already
kind
of
solved
this
well,
we
have
a
solution
to
it.
I
don't
know
if
we've
solved
it
completely,
but
it's
something
that
the
user
gets
to
define.
The
idea
is
that,
if
there's
something
that's
unrecoverable
by
something
in
the
export
pipeline
that
it
gets
pumped
up
to
what
we
call
an
error
handler
of
some
sort
and
there's
a
global
defined
one
that
is
just
as
is
kind
of
listed
in
this-
that's
logged.
G
G
F
When
do
you
call
this
error
handler
for,
for
example,
if
the,
if
the
call
to
exporter
time
times
out
once,
do
you
call
this
error
handler,
or
do
you
call
it
only
if
you
know
this
is
fatal
and
you're
not
gonna,
be
able
to
export
like
yeah.
G
G
You
would
you
would
call
this
yeah
on
the
transient
error,
you
you
well,
if
yeah,
sorry,
if,
if
like
say
the
exporter
has
retries
built
in
it,
would
just
do
the
retries
and
it
wouldn't
actually
notify
this,
because
it's
not
actually
it's
handling
the
error
right
but
like
if
it
if
it
gets
to
the
point
where,
like
the
retries
time
out
or
something
like
that,
it
will
send
this
error
upstream
at
that
point.
But
is
it
not
so
so?
But
as
you,
the
idea.
G
The
hair
gets
sent
upstream
if
the
user
or
the
the
actual
operator
of
the
actual
instrumentation
says
like.
I
don't
really
care
about
these
errors.
They
can
build
an
error
handler
that
can
filter
them.
They
can
build
an
error
that
just
ignores
them.
Is
the
idea.
D
G
But
I
mean
that's
the
thing
like
because
there's
there's
the
users
of
this
are
going
to
have
different
opinions
right
like
we're
all
having
different
opinions.
I
guarantee
the
users
are
going
to
have
different
opinions
had
to
handle
it,
and
that
was
why
the
idea
was
just
build,
an
interface
where
they
can.
They
can
put
their
solution
in
and
then
by
default,
we'll
just
give
them
what
they
want.
Well,
they
give
them
notification,
but
also
also
do.
F
G
Yeah,
that's
a
good
question
and
go
as
you
know.
You
know
we
just
pass
an
error
like
it's
just
there's!
No,
like
logging
constructs
around
that,
like
it's
just
an
error,
how
you
want
to
classify
that
is
up
to
you
and
then
to
that
same
point
like
instead
of
reinventing
the
wheel
like
the
error
handler
by
default
and
go,
is
super
simple?
It's
it's
just
a
you
know
you
get
an
error
and
there's
no
severity
to
it.
P
Yeah
yeah,
I
think
that
there's
some
per
language
things
that
can
change
here
like,
for
example,
like
we
could
leverage
in
the
java
api.
There
is
a
pretty
robust
logging
library,
where
you
can
register
your
own
handler
if
that's
the
route
that
we
want
to
go
and
that
sort
of
has
some
severity
built
into
it.
So
I
think
that
kind
of
differs
on
a
language
by
language
basis,.
M
G
It's
the
same
thing
that
mitchell
was
saying
like
if
you
know,
if
the
sdk
has
a
has
the
ability
to
try
to
recover,
do
that
and
don't
let
the
user
know,
but
if
yeah,
if
it
comes
to
the
point
where
I
can't
actually
deal
with
it
like
it,
right
user
probably
has
a
better.
F
But
but
but
the
interesting
part
going
deeper
again,
let's
assume
in
the
future.
We
add
we
we
now
back
everything
we
we
say
we
throw
everything
back
to
the
logging,
but
but
for
metrics.
Let's
assume
metrics
metrics.
We
cannot
explore
metrics,
we
send
back
the
error.
User
builds
metrics,
but
these
metrics
cannot
be
sent
because
we
we
have
a
problem.
G
I
guess
bare
bones
of
the
solution
as
possible,
but
I
I
agree
with
kind
of
what
I
think
mitchell
was
just
saying,
like
it's
going
to
be
language
specific
like
to
us.
Like
you
know,
we
have
a
really
bare
bones:
logger,
like
let's
just
use
that,
like
maybe
there's
other
languages
that
have
you,
know
really
sophisticated
systems
to
handle
these
kinds
of
things,
and
I
think
the
specification
should
probably
even
open
to
those
languages
to
do
like
the
idiomatic
form
of
what
that
language
would
expect
to
have
done.
Q
G
Know-
and
I
I
can
make
a
lot
of
language,
jokes
and
trashing
on
at
this
point,
but.
G
I
I
don't
know
like
that.
Maybe
that's
like
idiomatic
in
the
language.
F
One
one
last
question:
for
example:
if
user
gives
you
a
nil
or
empty
string
for
for
a
span
name-
and
we
don't
expect
that-
I
don't
know
if
that's
the
case
or
not,
but
I'm
just
giving
if
you
have
invalid
input
from
the
user.
Are
you
are
you
calling
this
handler
or
that's
something
that
you
are
just
not
calling.
G
These
I
yeah
it's
I'd,
have
to
look
because
that
seems
a
little
bit
specific.
You
know
like
maybe
when
they're
actually
setting
the
name
or
setting
these
values
like
it's
actually
returning
the
error
at
that
point
in
the
code,
but
I
think
I
think
you're
right
like
maybe
it's
not.
G
You
know
like
like
a
tracer
name
like
if
you
don't
specify
a
tracer
name
like
that's
a
great
example,
because
the
sdk
has
a
defined
way
to
recover
from
this,
and
that's
just
to
use
a
default
instead
and
so
it'll
just
use
the
default.
No
error
is
going
to
get
sent
up,
no
error
is
going
to
get
notified
and
the
default
will
actually
be
included,
but
yeah.
G
But
I
also
think
that
it's
really
you
know
I've
been
in
a
situation
where
I've
configured
something
really
poorly
and
gone
and
run
it
for
a
day
and
looked
after
the
day
and
go
like
where's
all
my
data
and
it
going
like.
Oh,
I
screwed
up
and
like
the
logs,
are
just
full
telling
me
where
I
messed
up
and
that's
really
useful.
K
So
go
ahead,
charlie,
a
couple
questions
so
like
first
like
would
we
expect
those
error
handling
thing
to
be
provided
as
a
callback
and
run
synchronously
in
the
user's
code,
or
it
should
always
be
a
notification,
and
even
if
the
user
decided
to
sleep
over
that,
you
know
it's
not
going
to
block
their
other
api
calls.
The
second
one
is:
do
we
expect
this
just
as
a
like
troubleshooting
feedback,
so
there's
no
way
for
the
user
to
change
the
behavior
of
the
application,
or
we
actually
believe
we
should
give
enough
information.
G
Yeah,
I
think
those
are
some
good
questions.
I
think
for
the
first
question
is
to
like
whether
this
would
be
synchronous
or
sickness
like
in
in
go
it's
it's
very,
it's
the
end
of
the
pipeline,
like
there's
no
like
feedback,
essentially
by
the
default.
So
I
think
if
that
should
be
something
that
is
somewhat
language
specific,
like
you
have
to
derivatives
for
some
sort
of.
G
Feedback
boost,
I
think
you
should
probably
try
to
optimize
those
to
make
it
again
like
idiomatic
and
then
again
like.
I
think
that
if
you
wanted
to
have
some
sort
of
like
way
that
a
user
tries
to
solve
an
issue,
I
think,
as
as
we've
designed
it
and
go
like
they
can
do
that
right
now
like
if
they
get
an
error
and
it
gets
passed
up
to
their
error
handler
and
they
have
some
solution
in
their
mind.
That's
how
like
maybe
they
want
to
flip
the
network
and
restart
the
network
or
something
like
that.
G
That's
left
to
them
at
that
point
from
the
design
and
go
but
again,
like
I
said
like
if
you
have
good
primitives
in
the
language
to
try
and
automate
that
process.
Maybe
you
tried
building
that
in.
I
guess
is
the
idea.
K
I
see
in
that
way
it
seems
like
difficult
to
get
this
into
the
spike
across
the
language,
and
probably
we
can
leave
that
for
individual
sdk
to
do
whatever
they
want
and
mention.
As
long
as
there
is
a
general
mechanism
for
the
user
to
subscribe,
what's
happening
like
what's
going
wrong
in
ick,
that
should
be
fine.
F
I
think
yeah
there
are
there
is
there.
Is
this
part
that
needs
to
be
stated
that
we
want
to
defer
to
the
user
to
decide
on
these
errors?
That's
one
thing,
so
that
means
every
language
has
to
do
whatever
is
more
idiomatic
for
the
language
to
do
that.
Secondly,
is
the
the
the
types
of
errors
describing
whatever?
What?
When
do?
We
call
this,
as
tyler
said
like
for
things
that
we
we
have
default
behaviors
even
for
invalid
things
or
for
for
errors.
We
should
apply
the
defaulting
without
calling
this
handler.
F
If
and
for
others,
we
should
not.
We
should
call
this
so
just
just
describing
when
this
this
errors
or
exceptions
or
whatever
you
call
them
are
reported
to
the
user
and
the
fact
that
this
mechanism
should
be
should
be
in
the
specs
and
then
every
language
defines
whatever
and
how
we
implement
it.
M
F
Okay,
who
takes
this
as
an
action
item.
D
F
Next
item
next
item
is
very
simple:
it's
just
like.
Should
we
do
that,
should
we,
which
we
currently
have
the
default
sampler
defined,
as
always
on,
which
means,
even
if
we
receive
a
an
unsampled
trace,
we
will
turn
it
on
the
flag,
based
on
the
description
of
always
on
the
proposal
is
to
to
change
it
with
another
sampler
that
we
have
defined,
which
is
parent,
current
or
else
always
on,
which
means
we
first
respect
parent.
If
there
is
no
parent,
we
we
always
own
seems
reasonable
to
me.
F
F
Okay
decision
create.
D
M
Yeah,
thank
you.
I
hope
soon
doesn't
start
failing
again
for
me
so
yeah.
Basically,
this
is
a
pr
for
for
having
the
global
propagators
default
to
no
op
implementation.
M
The
idea
is
that
we
can
provide
out
of
the
box
proper,
some
out
of
the
box
propagators
like
trace
context,
but
we
don't
do
any
inter
process
propagation
out
of
the
box.
You
know
just
to
not
surprise
the
user
that
they,
just
they
usually
just
bring
in
the
api,
and
they
are
seeing
that
there's
some
actual
network
stuff
happening
yeah.
So
basically,
I
would
like
to
get
the
feedback
overall
there.
There
were
some
comments
from
daniel
dayla
from
javascript,
but
yeah.
M
F
F
That's
that's
what
I
was
referring
by
a
grpc
or
http
client,
any
instrumentation,
so
yeah,
I
I
don't
know.
I
like.
I
like
the
fact
that
we
we
make
tracing
we.
By
doing
this,
we
may
we
make
tracing
more
more
general
available
and
more
more
friendly
to
the
propagation
by
by
having
this
like,
but
I
do
see
the
problem
that
you
are.
You
guys
are
mentioning
here.
Probably
what
we
can
have
is
we
can
have
a
different
trade-off.
F
The
api
comes
with
the
with
the
w3c
propagator
inside
and
maybe
that's
not
enabled
by
default
and
maybe
is
just
an
environment,
variable
a
system
property.
Whatever
is
the
national,
the
the
natural
thing
in
that
language
to
enable
this
without
having
to
include
the
sdk.
So
that
may
be
a
good
trade-off.
M
Well,
you
know
one
of
the
proposals
which
is
slightly
different
to
what
you
just
said
is
that
the
api
brings
the
trace
propagator,
but
it's
not
installed.
So
if
the
user
has
to
enable
that
they
have
to
manually
install
it.
M
F
Yeah
I
like
that,
I
think
I
think
it's
a
reasonable
start,
at
least
having
that.
N
Yeah,
I
just
don't.
I
don't
see
what
makes
like
the
propagators
different,
that
it
needs
a
working
implementation
in
the
api,
but
nothing
else
does.
Q
N
What
what
makes
this
somehow
more
blessed
than
anything
else
like
you
know,
tracers
or
something
like
that
again?
Where
do
you
draw
the
line?
It
seems
to
me
the
api
is
the
api
and
it's
just
an
api.
It
does
nothing
if
you
have
no
implementation,
and
I
I
think
the
use
case
of
using
the
api
without
an
sdk
is
going
to
be
such
a
like
niche
small
percentage
of
users
that
it
seems
like
we're
bending
over
backwards
to
support
this.
Like
point
zero
one
percent
use
case,
I
see.
F
Maybe
maybe
maybe
we
can,
maybe
maybe
the
real
api
should
come
with
the
blank
blank
knob
completely,
no
and
then
have
a
propagation,
only
sdk
or
whatever
you
call
it,
which
implements
the
the
propagators
some
of
the
propagators
which
may
implement
the
context
part
in
javascript,
which
may
implement
the
tracer
to
just
propagate
the
parents.
Context,
if
called
with
start.
N
F
It's
not
necessarily
unreasonable.
It.
F
N
R
Yeah,
this
feels
very
similar
to
an
issue
that
we
had
in
the
go
sdk
where
someone
was
asking
for
istio
trace
forwarding
only,
and
I
feel
there
that
the
the
work
needed
to
set
up
just
a
propagation
only
integration
is
the
same
work
that
is
necessary
to
actually
participate
in
the
trades
with
our
instrumentation.
You've
still
got
to
configure
your
your
your
input,
propagators
to
extract
the
context,
information
and
your
export
propagator
to
inject
it
into
downstream
requests.
R
F
F
I
would
like
one
one
by
the
way
I
wanna
ask
sergey
for
feedback.
Sergey
was
one
of
the
big
supporter
of
having
this
enable
by
default.
I
don't
remember
all
his
arguments,
but
if
he
he's
the
only
person
that
I
know
was
a
big
supporter
of
this
for
me,
you
you
guys
convinced
me
we
can
go
with
a
completely
no
in
the
api
for
four
things.
F
F
Let's,
let's
make
sure
we
ask
sergey
for
the
la
his
opinion
and
if
he
is
okay
with
this,
I
I
think
we
should
move
forward
with
the
complete
knob
part
on
the
api
and
then
maybe
discuss
if
we
have
the
ability
to
configure
our
sdk
with
that
propagation,
only
or
we
work
a
bit
and
provide
a
separate
sdk
called
propagation.
M
Only
okay,
so
action
item
somebody
needs
to
talk
to
sergey
or
block
him.
Can
you
do
that
bogdan
or
should
I
do
that.
M
M
M
Of
course
it
might
even
change
after
the
the
the
contents
of
the
previous
pr,
but
the
idea
is
just
that.
We
specify
a
few
basic
things
like
so
at
this
at
this
moment,
without
the
changes
from
the
previous
pr,
where
we
would
be
putting
trace
context
that
this
propagator
in
the
api
and
the
rest
will
be
in
the
open,
telemetry
official
artifacts
or
packages
yeah.
F
Give
a
bit
of
context.
In
java,
for
example,
we
decided
to
have
some
some
artifacts
that
depend
only
on
the
api
and
we
call
them
extensions
or
api
extensions,
and
these
api
extensions
are
artifacts
that
depend
purely
only
on
the
api
that
we
we
have
and
this
api,
as
I
said,
the
api
being
just
the
api
artifact,
and
I
think
I
think
a
propagator
should
not
depend
on
anything
else.
Besides
the
api,
correct.
M
M
N
N
Other
than
like
the
the
context
stuff
like
in
js,
we
have
a
core
package
that
implements
like
very
low
level
things,
and
we
would
have
to
depend
on
that.
But
it
is
it's
not.
D
N
M
Okay,
great
thanks
so
much
okay,
so
that
that's
that's
it
next
item,
oh
yeah!
This
is
a
small
one.
Also
it's
removing
http
from
http
text
format.
There
was
initial
agreement.
M
Q
Do
http
headers
support
non-ascii,
otherwise
it
should
be
named
something
like
ascii
text,
propagator
or
whatever.
E
Q
F
Restriction
on
this,
we
are
not.
We
are
not
confusing
users
because
of
the
renaming,
because
it
feels
that
we
are
using
this
text
format
in
blank
in
as
http
headers
without
any
encoding
previous
encoding.
We
are
just
putting
them
so
so,
actually,
the
restriction,
the
the
fact
that
is
called
http,
maybe
maybe
it
should
be
http
header,
but
the
fact
is
it
implies
that
there
are
some
restrictions
on
the
encoding
and
possible
things
that
you
can
put
there.
So
so
probably
we
should
I
I
don't
know
all
the
restrictions
on
the
headers.
F
N
Unexpected
look,
it
looks
like
headers
officially,
according
to
the
spec
use,
a
iso
8859-1
character
set,
which
is
essentially
us
ascii.
They
do
allow
for
rfc,
2047,
mime
and
coding
for
non-ascii
values,
but
this
says
client
support
or
actual
support,
for
that
is
yeah,
non-existent.
N
I
would
be
in
support
of
that
just
because
it's
a
more
descriptive
like
this
is
what
the
actual
restriction
is.
You
can
only
use
ascii
values.
It
makes
it
more
clear
why
we
did
it.
F
Yeah
add
me
into
that
camp
as
well.
Okay,
so
it
seems
that
there
is
an
agreement,
carlos
double
check,
the
the
encoding.
If
you
or
who
has
this
you
have
it
assigned
yeah.
M
L
L
In
last
week's
meeting,
we
talked
about
the
defining
ga
performance
goal,
so
I
started
to
creating
a
draft
and
for
the
draft
I
put
some
the
most
obvious
and
important
metrics
for
our
c
plus
plus
sdk
there,
including
instrumentation
cost
and
the
events
throughput,
so
that
I
put
some
hard
coded
numbers
which
comes
from
our
internal
code
base
and
also
our
experience
like
the
instrumentation
cost
and
that
value
comes
from
etw
but
yeah
feel
free
to
comment
or
I
I
already
saw
some
comment
on
there
in
the
pr
which
says
we
should
make
the
numbers
configurable
yeah,
feel
free
to
comment
on
the
draft
for
performance.
M
Perfect
yeah
yeah
yeah.
I
thought
I
saw
some
action
from
some
comments
from
tigran,
so
yeah.