►
From YouTube: 2022-09-06 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
C
C
A
All
right,
let's
start,
okay,
so
the
first
one,
the
pr
that
just
clarifies
agent
versus
the
client
thanks
for
the
pr
peter
wow.
I
think
it's
it's
very
useful.
I
did
another
pasta.
I
left
a
few
more
comments.
I
would
like
some
more
reviews
on
this.
Like
more
opinions
before
we
make
the
call,
I
guess
andy.
A
A
I
just
want
to
make
sure
we
don't
in
some
places
we
don't
add
confusion
by
referring
to
agent
versus
client.
So
I'm
I
I'm
a
bit
worried
about
the
dangers
of
that,
but
I
think
in
some
places
it
definitely
works
much
better.
With
with
the
current
warning.
A
I
think
he
yeah
sean
also
commented
saying
that
he
liked
it,
but
that
was
the
extent
of
the
comment,
so
hopefully
he
can
provide
some
more
can
expand
on
what
he
liked
and
yeah
anyway.
I
I
would
like
to
see
more
eyes
on
this,
and
if
there
are
no
objections,
I
guess
if
we
like
it
more,
if
we
think
it's
not
positive,
then
we
should
probably
merge
it,
but
no
rush
with
this.
I
think
it
doesn't
change
any
semantics.
It
doesn't
block
to
release
in
any
way.
A
Okay,
cool
so,
and
also
as
I
was
reading
the
changes,
I
noticed
a
couple
more
unrelated
issues,
so
created
submitted
a
couple
more
new
issues
there.
There
is,
I
linked
it
from
there.
One
is
to
delete
some
wording
from
the
spec
I
will.
A
I
will
not
do
that
until
this
pr
is
merged,
because
it's
going
to
result
in
conflicts,
but
it's
it's
easily
doable
so
another
one
I
wanted
to
ask
about
is
so
we
we
currently
say
that
the
compression,
when
the
server
sends
to
the
client
is
a
possible
option.
We
use
the
the
wording
we
say:
may
the
server
may
compress
if
the
client
accepts
the
the
gzip?
A
A
Yeah
the
spec
currently
says
that
the
server
may
compress
if
the
client
accepts.
So
I
think
that
we
should
say
that
the
server.
C
A
Come
better
yeah.
I
agree:
okay,
cool
I'll
make
that
change.
I
think
that's
that's
the
right
approach
there,
because
we
did
the
same
thing
with
ltlp
and
I
don't
see
any
any
downsides
in
in
our
use
cases.
In
particular,
there
may
be
some
slight
increase
in
cpu
usage,
but
I
think
it's
a
no-brainer
anyway.
A
All
right
cool,
I
think
there
is
only
one
more
remaining.
I
don't
know
if
you
have
time
to
look
into
that
and
the
the
frame
size.
C
You
know
I
spent
some
time
looking
so
the
way
I.
C
Interpreted
that
was
that
there
was,
I
wasn't
exactly
sure,
quite
sure
what
frame
size
meant
with
regard
to
web
sockets.
But
my
understanding
at
this
point
is
that
it's
it's
effectively
the
size
of
a
single
message
going
across
the
websocket,
where
the
so
my
understanding
would
be
the
the
compressed
protobuf
would
need
to
fit
within
that
size.
Limit.
A
A
I
don't
know
what
exactly
the
problem
could
be,
but
it's
essentially
the
recipient.
The
recipient
is
supposed
to
reconstruct
the
message
by
stitching
together
the
frames
that
is,
that
is,
that
happens
on
completely
different
obstruction
level.
We
don't
we're
not
aware
of
that.
In
our
implementations.
A
That's
a
concern
of
the
websocket
implementation.
However,
if
I
remember
correctly,
the
concern
was
that,
if
the
frame
size
that
the
client
uses
exceeds
the
capability
of
the
server
to
receive
that
single
frame,
then
the
server
may
not
be
able
to
accept
it.
A
I
don't
know
if
there
is
any
sort
of
negotiation
happening
on
the
frame
size
when
the
connection
is
established
and
whether
that
is
the
problem
right,
maybe
that's
that's
like
the
client
assumes
it
can
send
100
megabyte
frames
and
the
server
simply
does
not
have
the
sufficient
size
of
the
buffer
to
receive
that
right.
Something
like
that.
A
A
C
The
yeah
just
looking
at
the
go
implementation,
there's
a
default
max
payload
of
32
megabytes,
so.
A
It
may
be,
warfares
are
also
trying
it
because,
with
compression
32
megabytes
like
that,
the
largest
thing
that
will
go
into
the
messages
is
going
to
be
something
like
the
configuration,
which
is
a
text
most
likely,
which
is
highly
compressible.
So
my
gut
feeling
is
that
32
megabytes
should
be
more
than
enough
in
vast
majority
of
cases.
If
that's
a
typical
default
for
websocket
implementations,
but
if
it's
uncompressed
size
then
it
may
be
more
worrying.
A
C
My
it
isn't
obvious
to
me,
it
seems,
like
some
cases
are
referring
to
payload.
Some
are
referred
to
a
frame
interchangeably
and
it's
not
clear
if
a
payload
is
and
a
frame
are
also
distinct
from
a
message
yeah,
so
I
will
spend
some
more
time
on
it.
Okay,.
C
Something
that
was
a
quick,
easy
answer,
but
I
think
you
found
that
originally
when
you're
trying
to
look
forward
as
well.
So
I
I
will
dig
into
the
rfc
and
and
look
at
the
go
implementation
and
and
maybe
try
to
look
at
a
a
node
or
some
other
implementation
as
well
and
see.
If
we
can
see
if
I
can
at
least
provide
some
more
color.
A
C
Okay,
the
other
thing
I
intended
to
do
for
this
week
and-
and
I
apologize
the
labor
day
weekend-
ended
up
being
a
travel
weekend
for
me-
makes
a
little
bit
extended,
but
I
had
hoped
to
make
a
proposal
on
custom
messages.
I've
done
quite
a
bit
of
thinking
about
it.
C
I
I'm
at
this
point,
leaning
and
I
could
explain
my
reasoning
when
I'll
I'll
actually
write
it
up
in
an
issue
at
this
point,
leaning
toward
a
a
string
type
with
a
string
body,
and
the
reasoning
is
that
if
we
use
any
value,
then
you
end
up
writing
a
lot
of
code
to
manually
map
any
value
into
some
some
native
struct
and
go,
and
I
think
that
there's
an
advantage
to
being
able
to
either
unmarshal
json
or
unmarshall,
and
I
think,
if
you,
if
you
deal
with
this,
I
was
just
concerned
about
a
byte
array
and
how
that
might
create
encoding
issues
across
language
boundaries.
C
A
A
Think
I
agree
with
you:
yeah
yeah,
with
any
value
I
think
you're
totally
right.
It
doesn't
really
help.
It
actually
creates
more
problems
with
regards
to
strings
versus
bytes,
I'm
not
so
sure,
because
this
is
going
to
be
agent
specific
right.
We're
saying
that
the
agent
and
the
server
are
free
to
agree
on
the
whatever
reason
yeah.
C
I
just
I
just
didn't
want
if,
if
somebody
had
chosen
to
write
a
node
server
with
a
go
agent,
are
they
going
to
have
to
jump
through
extra
hoops
to
understand
the
byte
array,
but
probably
probably
not
probably
they'll
both
be
they'll,
decode
them
to
utf-8
strings
and
then
decode
them
as
json
or
something?
But
if,
if
we
start
with
a
string,
I
think
we
can
be
fairly
safe,
that
somebody
will
choose
a
encoding,
that's
safe
to
transmit
the
stream
worst
case.
They'll
be
64
encoded
if
they
want
a
byte
array.
A
A
Whatever
string
means
in
the
particular
language,
when
you're
dealing
with
a
string
field,
type
versus
the
pi
type
about
you're,
saying
interoperability
when
you're
using
bytes
may
be
worse
than
using
strings,
I'm
not
so
sure
about
that,
because
you're
you're,
because
strings
mean
different
things
in
different
languages
and
those
limitations
are
actually
different.
So
it
may
be
that
unless
you
heavily
restrict
to
what
that
string
can
represent
like
it
can
be
only
valid
utf-8
sequences
which
hopefully
are
representable
in
every
language
that
we're
interested
in.
A
C
C
Can
I
reliably
you
know
on
in
in
node
I
would
json
parse
a
string
to
get
to
get
that
object
from
that
json.
You
know
I.
If,
if
I
were
receiving
a
byte
array,
I
guess
I
would
just
json
parse
the
string
of
the
right
array.
C
C
You
know
in
java
you
would
probably
have
to
specify
an
encoding
when
you
created
your
string
to
be
safe,
you'd
probably
choose
utf-8
and
then
you'd
parse
as
json,
but
I
think
usually
those
parsing
are,
I
should
say
in
the
languages
I've
dealt
with
about
half
of
them,
you're
parsing
for
bytes
and
about
half
of
them,
you're
parsing
from
strings,
but
if
you're,
if
you're,
parsing,
json
or
yaml,
or
some
some
string
based
encoding,
where
it
seems
safer
to
me
to
rely
on
a
string
and.
C
And
again,
if
you
want
to
support
bytes
past
them,
basics
before
encoded
or
some
other
lighting
coding
that
you
you,
you
know,
both
both
sides
of
the
exchange
agree
with.
A
C
C
B
C
It's
it's
not
a
huge
difference
and
I
guess
I
I
felt
more
confident
in
passing
a
string
around.
If
it's
a
string
based
encoding,
then
then
passing
a
way
around.
A
A
C
As
like,
you
know,
an
http
post,
where
you
have,
you
know
a
path
and
a
body
and
that's
all
you
get
and
it's
up
to
you.
B
A
B
Well,
I
just
want
to
say,
hi
and
introduce
myself-
I
mean
broad
from
from
epstein
acquired
by
cisco
and
we're
evaluating
this
project,
we're
doing
now,
poc
to
more
specific
to
agents
to
other
agents
than
collector,
and
this
seems
like
a
very,
very
interesting
and
and
innovative
project
that
would
like
to
take
part
hopefully
to
take
issues
and
and
help
with
it.
A
Hi
and
welcome
it's
it's
great
that
you're
evaluating
it
we're
very
open
to
whatever
suggestions
you
have.
We
are
right
now
considering
the
the
protocol
is
currently
declared
peta
and
we're
considering
declaring
its
table
soon.
So
now
is
a
is
a
great
time
if
you
have,
if
you
see
any
limitations,
anything
that
you'd
like
to
be
changed.
Anything
that
is
specifically
not
an
additive
change
that
can
be
added
later
now
is
a
great
time
to
make
those
proposals.
A
So
please
do,
please
feel
free
to
file
any
issues
any
anything
that
is
inconsistent
in
the
specification.
So
any
concerns
you
have
please
please
do
let
us
know
and
you're
very
welcome
thanks
for
joining
thanks.