►
From YouTube: 2022-01-20 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).
B
B
E
Hi
good
morning,
all
or
good
evening,
let's,
let's
start
in
maybe
about
one
or
two
minutes.
E
E
The
first
point
on
the
agenda
is
about
the
pr
that
I
submitted
yesterday,
because
we
were
talking
last
week
about
a
pool
receive
instrumentation
like
ludmilla
was
working
or
she
was
presenting
this
this
document
and
we
kind
of
agreed
with
her,
that
this
optimal
optimal
solution
for
those
scenarios
would
be
to
would
be
based
on
allowing
adding
inks
after
starting
a
span.
It
is
currently
not
allowed
by
the
open,
telemetry
specification,
so
you
can
only
add
links
when
the
span
is
created,
but
one
cannot
add
links
after
creating
a
span.
E
So
we,
after
starting
discussing
the
solutions,
we
kind
of
converged
on
this
solution
here
being
the
ideal
solution
for
our
scenario,
and
we
also
agree
that,
for
me
it
was
an
action
item.
I
will
bring
this
to
this
back
meeting.
It
was
on
tuesday
and
also
open
pr
and
yeah.
I
brought
us
to
the
spec
meeting
people
there
that
were
don't
really
had
any
objections.
E
They
opened
the
pr
and
yeah
the
pr
is
open
now
and
there's
already
some
discussion
going
on,
so
it
let's
see
how
how
this
will
go.
E
I
expect
there
to
be
a
quite
some
more
discussion,
because
it
is
how
to
say
a
bit
of
a
compatibility
break
that
we
add
by
this
by
this
feature,
that
we
allow
spank
creation,
allow
adding
links
after
span
creation,
because
yeah
there
might
be
samples
out
there
that
rely
on
the
fact
that
all
the
links
are
added.
It's
bank
creation.
E
I
think
it
should
not
that
big
should
not
be
that
big
of
a
deal,
and
I
also
tried
yeah
to
make
some
points
here
that
if
we
really
want
to
remove
this
limitation,
we
should
do
it
now,
because
vans
are
not
really
invite
use
now,
and
I
think
it
would
be
less
painful
to
do
it
now
than
later,
because
that
was
something
that
bogdan
was
pushing
for
to
first
work
out
the
proper
sampling
story
and
then
and
then
kind
of
decide
on
this.
E
I
slightly
disagree
with
this
because
I
think
the
longer
we
wait,
the
more
white
use
fans
will
get
and
the
harder
it
will
be
to
actually
change
something
in
the
specification
related
to
spence.
But
let's,
let's
see
where
this
discussion
goes,
what
other
people
say?
So
if
you
maybe
maybe
just
want
to
add
some
comments
or
thumbs
up
here,
that
might
be
of
some
help
so
that
people
see
that
yeah.
There
is
a
kind
of
some
that
there
are
kind
of
other
people
who
are
kind
of
interested
in
that
feature.
E
Otherwise,
yeah,
let's
see
where
this
discussion
goes
so
so
far,
I'm
not
sure
how
how
how
that
will
end,
whether
the
pr
will
go
through
or
not,
and
that
will
kind
of
then
yeah
impact.
Also,
our
this
will
impact
our
options
here.
So
I
think
we
cannot
yet
decide.
E
Definitely
if
we
want
to
kind
of
really
stick
with
solution
too,
I
think
ideally
we
will,
but
we
might
need
some.
We
might
also
if
the
discussion
goes
longer,
maybe
think
about
some
four-pack
solution
that
we
keep
in
back
of
our
minds.
F
Right
here
I
feel
like
this
is
a
case
where,
if
they're
gonna
say
no,
we
need
to
ask
the
tc
to
review
our
messaging
model
right,
because
it
feels
to
me
like
there's.
There's
like
a
disconnect
like
yuri
and
bogdan,
are
kind
of
saying,
like
links
are
supposed
to
represent
causality,
and
so
you
know
they
can't
happen
after
a
span
is
created
and
we
don't
want
to
be
creating
links.
F
You
know
all
over
the
place,
but
I
feel
like
maybe
like
a
side
effect
of
this
is,
is
maybe
proposing,
perhaps
maybe
at
the
the
main
spec
meeting
or
otherwise
getting
the
tc
members
to
be
like.
Can
you
look
at
our
messaging
model
here,
because
this
seems
very
straightforward
to
us
that
it
would
work
this
way
like.
E
Yes,
I
think
if
we,
if,
if
open
telemetry
altogether,
would
adopt
such
a
strict
like
a
model
on
when
it
is
allowed
to
create
links
that
would
have
some
impacts
on
us
in
messaging
yeah,
because
we
kind
of
yeah
we
would
rely.
We
rely
heavily
on
with
our
in
our
current
thinking
on
a
more
kind
of
how
to
say
lenient
model
on
yeah
writing
games.
F
If
the
k
like
I
I
just
yeah,
I
would
like
to
make
sure
we
clear
up
whether
or
not
there's
some
some
deeper
disagreement
about
how
how
to
model
transactions
in
general.
It
sounds
like
maybe
yuri
and
bogdan
actually
have
have
a
different
model,
maybe
than
the
one
we've
been
working
with,
and
it
would
be
good
to
clear
that
up.
E
Yes,
definitely
I
mean,
I,
I
think
we're
not
doing
much
new
here.
I
think
also
the
link
model
in
the
in
the
previous,
like
draft
of
the
messaging
semantic
conventions,
is
not
one
based
on
causality.
E
It's
just
that
kind
of
figure,
try
to
think
it's
way
more
detailed,
but
I
think
it's
not
that
we
basically
add
something
on
top
of
what's
already
there
in
the
existing
semantic
conventions
in
terms
of
of
the
link
model,
but
I
think
it's
good
to
kick
off
this
this.
This
discussion
now
just
to
make
sure
also
for
us
where
we
are
where
we
are
going
here.
E
So
ludmila
is
not
here
today,
so
not
sure
if
she
will
join
in
later,
because
I
would
have
loved
to
continue
discussing
her.
E
Her
document
here
for
pull
receive
instrumentation,
but
let's
wait
a
bit,
maybe
maybe
she
will.
She
will
still
show
up
and
let's
try
to
talk
about
this
point
I
I
came
up
with
that
to
just
summarize
what
I
mean
our
like.
The
goal
is
just
to
get
this
out
ready
up
for
review
and
for
this
group
I
just
yeah
try
to
put
together
things
that
we
still
need
to
that.
E
We
need
to
discuss
in
this
forum
and
to
come
to
some
kind
of
agreement
or
consensus
to
to
kind
of
that,
our
prerequisites
for
for
putting
up
this
out
tip-
and
maybe
we
can
just
go
through
this
and
then
also
see,
if
there's
other
things
from
from
your
side
that
I'm
missing
here,
but
just
to
give
us
some
kind
of
guideline
of
how
far
we
are
and
where
we,
what
still
needs
to
be
done
and
where
we're
going
so
we
discussed
context
propagation
pretty
extensively.
E
E
Mqb
mqtt
http
are
the
three
ones
that
I
think
are
the
most
important
ones
where
we
should
have
like
some
story
there
that
we
need
to
cover,
and
I
was
attending
one
of
the
last
w3c
meetings
and
asking
them
about
those
drafts.
Wcc
trace
context,
extension
drafts
for
mqb
and
mqtt,
and
I
cr
I
shortly
presented
our
model
that
we
have
for
context
propagation
and
for
the
people
attending
there.
E
They
said
that
make
sense
to
them
and
we
can
have
feel
free
to
make
to
submit
pull
requests
with
changes
that
we
need
in
those
mqb
and
mqtt
drafts
for
for
for
w3c.
E
So,
basically,
by
by
doing
that,
we
would
we
would
cover
mqp
and
mqtt
here,
because
if
those
wcc
extensions
extension
specifications
kind
of
cover
our
use
cases,
we
can
just
like
link
to
those
and
will
be
covered.
E
I
will
probably
try
to
find
some
time
to
talk
with
canons
about
that,
because
he
co-authored
those
extensions,
and
maybe
him
and
I
together
can
work
on
on
kind
of
adapting
them
so
that
they
meet
our
requirements
for
http.
I'm
I'm
not
sure
yet.
I
I
also
would
like
maybe
to
talk
to
kamens
here.
Maybe
somebody
else
here
has
an
idea.
E
They
could
just
recommend
using
cloud
events,
because
cloud
events
has
those
kind
of
two
layers
of
context
in
there
already,
but
I'm
not
sure
how
feasible
it
is
for
our
scenarios.
E
So
maybe
I
will
I'd
also
need
to
discuss
with
people
are
more
familiar
with
cloud
events
and
messaging
in
general
to
see
what
is
feasible
for
us
to
come
up
as
a
recommendation
for
http
to
kind
of
support.
This
layered
context
model,
but
I
I
think.
B
For
the
clouds
are
for
the
cloud
events
thing
for
http,
I
know
that
they
have
this.
I
mean
we
discussed
in
the
past
right,
but
they
have
this
extension
and
I
think
what
they
do
also
is
is
so
there
is
this,
so
they
add,
this
header
called
called
ce
for
like
like
it.
B
But
then,
if
you
use
this
the,
if
you
use
the
distributed
tracing
extension,
then
you
will
also
have
this
c
e
trace
parent
and
then
that,
where
the
context
creation
goes,
but
I
don't
know
if
that
will
persist
or
or
if
we
will
use
that
in
in
this
case,
for
for
http,
but
but
it's
very
specific
to
cloud
events
that
has
this
ce
dash
yeah.
So
maybe
the
same
name
or
something
like
that
that
we'll
use
for
for
amqp,
then
we
can
also
use
for
http.
E
I
mean
I'm,
I'm
I'm
not
sure
there.
Yet
what
is
the
best
and
most
kind
of
solution
here?
I
I
think
the
the
main
question
here
is
that
we
we
have
these
requirements
for
context,
propagation,
that
we
basically
pass
two
different
contexts
along
and
when
users
instrument
like
then,
according
to
our
automatic
conventions,
they
will
ask
you
how
to
do
this
for
http,
and
then
we
need
to
give
some.
E
We
could
just
I
mean
the
easiest
thing
would
just
say:
just
use
these
card
events,
extensions,
just
use
card
events
in
this
extension
and
that
enables
you
to
pass
like
two
contexts
along,
but
I'm
I'm
not
sure
if
that
will
like
be
an
acceptable
solution
for
everybody.
So
we
need
to
discuss
like
or
maybe
ask.
B
E
F
I
mean
yeah,
hey
sorry,
go
ahead,
dwayne!
No!
You
go
ahead.
Ted
I
was
just
gonna
say
I
personally,
I
mean
I'm
I'm
concerned
about
like
the
the
extra
complexity
of
having
these
two
layers
and
whether
it's
it's
needed,
and
I
would
love
to
see
this
play
out
in
production
before
we
go
about
trying
to
to
standardize
this
stuff,
just
because
I'm
I'm
a
little
suspicious
that
we're
we're
specking
ahead
of
production.
F
Given
that
we're,
given
that
we
we're
kind
of
like
we're
not
totally
sure
if
this
is
the
right
model,
I
don't
see
anything
wrong
with
with
camping
on
the
cloud
events.
You
know
headers
in
the
meantime.
F
If
people
want
to
do
this
and
then
we
could
just
just
see
if
that
catches
on
is
a
necessity,
if
it
doesn't
catch
on,
isn't
it
says
the
sf
cloud
offense,
then
there's
no
problem
at
all
if
it
does
catch
on
as
a
necessity
outside
of
cloud
events,
but
there's
something
about
the
way
they've
modeled
that
header-
that's
not
not
making
everybody
happy,
then
you
know
we
would
have
that
feedback.
C
C
You
know
hackish
or
whatever
that
cloud
events
as
a
specific
type
of
messaging
would
be,
would
specify
something
that
all
messaging
you
know
users
should
use,
but
maybe
to
ted's
suggestion
there,
if,
if
we're
kind
of
not
sure
use
that
for
now
and
and
decide
if
something
more
generics
needed
later,
it'd
be
nice
to
see
for
messaging
things
that
are
in
the
messaging
semantic
conventions
that
we
had
messaging
specific
headers
for
http.
If
they're
needed
like
instead
of
ce
dash,
maybe
msg
dash
create
or
something
you
know
what,
but,
but
I
understand.
F
Yeah,
maybe
another
way
of
putting
it
is
I
I
have
yet
to
what
maybe
you
are
dwayne?
You
are
coming
to
this
group
and
saying,
like
the
the
standard
trace.
Headers
are
like
not
not
working
for
my
messaging
system
and
I
need
I
need
more
here,
it's
more
for
me.
It's
that
I've
seen
the
cloud
events.
People
come
in
and
be
like.
Well,
we've
got
because
we
we've
got
this
meta
level
of
messaging
going
on.
F
We
we
need,
we
need
this
layer
cake,
but
I
haven't
seen
people
from
other
messaging
systems
show
up
being
like
this.
Http
thing
is
totally
not
working
for
me
and
you
know:
we've
modeled
a
fair
bit
of
not
every
use
case,
but
you
know:
we've
modeled
a
fair
bit
of
you,
know
stuff,
for
you
know
amqp
and
kafka
and
other
systems,
and
no
one's
come
back
from
that
instrumentation
and
been
like
this
just
isn't
working.
F
C
F
C
I
think
the
problem,
the
way
I
would
see
it
is,
if
you
know
we
like
saw
us
as
a
broker,
is
trying
to
implement
the
semantic
conventions,
as
it's
shaping
up
so
far
here
that
we
would
need
to
send
two
contacts,
because
we
would
need
to
send
our
contacts
for
the
kind
of
the
transport
layer
and
then,
in
order
for
the
subsequent,
you
know
receiver
application
to
link
to
the
create
there
needs
to
be
that
other
context,
and
so,
if
we
specify
in
the
semantic
conventions-
and
we
want
to-
you-
know-
abide
by
them-
that
that
this
link
should
be
created
by
the
receiver,
then
we
have
to
decide
how
to
transport
both
contexts.
E
E
Basically,
we
want
to
create
this
link
from
consumer
to
producer
and
if
we
propagate
context
via
http,
just
one
context
by
the
standard
mechanism,
it's
actually
not
clear
how
it
should
work,
because
on
the
consumer
side,
if
you
just
stick
like
trace
state
and
trace
parents
on
http
and
send
it
out,
and
how
would
you
tell
the
intermediary
to
kind
of
pass
on
this
context
without
changing
it,
because
that's
not
how
how
the
standard
like
http
trace
context
works.
Usually
the
intermediary
just
like
automatically
has
an
it
should
be
kind.
E
It
takes
it
and
just
puts
it
as
parent
on
like
on
on
on
an
outer
span
and
then,
when
it
kind
of
sends
like
out
to
the
consumer,
it
doesn't
send
out
the
same
context.
It
like
it
traced,
trace,
trace,
span
like
trace,
state
and
trace
parent
are
different
because
there's
a
different
span
id
that
causes
this
http
request
to
be
sent.
E
So
I
think
this
is
a
problem
there,
that's
actually
unanswered
in
the
current
in
the
current
messaging
semantic
conventions
that
we
have,
because
there
we
just
assume
that
the
context
from
the
producer
magically
somehow
is
available
in
the
in
the
data
context
from
the
producer
is
actually
somehow
magically
available
in
the
consumer,
but
we
don't
know
how
it
should
come
there.
E
For
example,
when
we
just
talk
about
http-
and
I
think
that's
quite
yeah-
one
of
one
of
the
trickier
questions
actually
to
answer
here
how
this
works,
because
I
think
it
will
not
work
with
the
standard
propagation
mechanism
when
we
just
think
about
http
because
like
when
we
talk
about
the
broker,
we
get,
the
broker
gets
an
http
request
in
and
sends
an
other
http
request
out,
and
it
would
need
basically
to
attach
the
same
trace
context
to
the
outgoing
request
that
it
receives
from
the
incoming
request,
and
that's
that's
not
usually
how
it
works.
F
Yeah,
that's
a
that's
a
a
really
good
point.
I
part
of
how
we've
been
getting
away
with
it.
I
guess,
is
by
leaving
presuming
that
those
brokers
are
just
black
box
systems
and
kind
of
focusing
on
the
the
single
message
approach.
E
Yeah
I
mean
we
know,
I
think
that
the
current
semantic
conventions
just
assume
that
brokers
are
not
instrumented
at
all
and
do
nothing
with
any
kind
of
com
they
receive.
So
in
that
kind
of
flight
it
somehow
works,
but
I
think
that
it's
not
a
sustainable
model
yeah
and
it's
like.
F
That
you
know
in
the
case
of
kafka,
the
way
we
get
away
with
it
is
kafka
actually
has
headers
on
messages,
and
we
actually
write
the
context
down
in
the
message
header,
which
I
think
is
closer
to
the
model
being
proposed
here
right,
which
is
saying
like
yeah
yeah
you've
got
some
transport
protocol,
but
actually
the
messages
themselves.
F
F
What
we're
modeling
is
like
context
per
message
and
we're
talking
about
messages
that
are
beefy
enough,
that
writing
that
context
down
on
them
doesn't
cause
the
whole
thing
to
fall
over,
which
I
don't
think
is
all
messaging
systems.
I
think
there's
where
the
message
is
small
enough
that
actually
that's
that's
a
doozy,
but
we're
not
talking
about
those
right
now.
F
I
don't
think,
and
one
of
the
issues
is
that,
while
kafka
has
a
place,
convenient
place
to
write
that
down
some
of
these
other
protocols
may
not,
and
if
they
don't,
then
we're
forced
to
put
that
message
in
the
transport
protocols
header,
which
is,
which
is
a
little
I
mean
I
guess
it's
that
that
works
when
you're
sending
one
message,
I
guess,
when
you
get
into
the
question
of
like
batching
messages
over
the
same
http
request,
for
example,
I
don't
know
if
that's
a
problem,
we
have
to
model,
but
that's
actually
an
example
where
this
also
this
wouldn't.
E
Yes,
that
that,
wouldn't
I
mean
with
when
we
talk
about
cloud
events
again,
I
mean
they
have
some
kind
of
solution
there,
but
it's
not
it
the
solution
that
they
have
for
this.
It's
not
using
the
kind
of
the
the
dce
headers
directly
in
the
hdb
message,
but
for
this
type
of
solution,
where
you
just
kind
of
have
like
a
json
blob
for
each
message
and
you
pack,
like
the
letters
in
there.
E
And
then
basically
have
this,
I
mean
in
that
regard.
You
would
have
then
the
one
trans
transport
context
or
the
http
message.
That
would
be
the
standard
like
trace,
parrot
and
trace
date,
header
on
the
http
message,
and
then
you
would
have
basically
the
creation
contexts
in
the
individual
kind
of
a
blog
tracing
blobs
right.
F
And
we
actually
have
explicitly
avoided
that
approach
in
the
past,
because
if,
if,
if
open
telemetry
did
something
like
that,
like,
in
other
words
for
messaging
systems,
where
there's
no
headers,
where
we
can
stick
this
stuff
in
the
message,
the
solution
is
to
be
like
cloud
events
and
say:
well,
actually
we're
going
to
apply
our
own
structure
to
this
message.
Where
now
the
message,
instead
of
just
being
payload,
is
some
structure
that
we're
applying
to
it
with
context
plus
payload
and
that
totally
works
provided.
F
Everything
in
the
system
like
like
with
cloud
events
like,
provided
that
everything
in
the
system
is
aware
of
the
fact
that
open
telemetries
hanging
around
or
open
telemetry
can
always
get
in
there
and
unwrap
the
thing
before
it
hands
it
off
to
the
part
of
the
system
that
that
isn't
aware
of
that
structure.
F
Then
then,
you
risk
breaking
stuff
right,
because
when
you
you
start
applying
this,
then
the
parts
of
the
system
that
aren't
aware
of
this
wrapper
are
going
to
to
smack
into
it,
because
they're
we've
just
shoved
it
into
the
payload.
Basically,
and
so
that's
like
the
cloud
events
approach,
I
think
right
is
like
where
they
say
it's
like.
Well,
you
go
end-to-end
with
cloud
events,
and
now
you've
got
this
kind
of
like
extra
layer
of
structure
there,
which
is
nice,
and
then
you
can
use
whatever
messaging
brokers.
F
You
want,
because
the
things
you've
kind
of
wrapped
that
whole
system
in
something
that's
aware
of
this
cloud
event
structure
and
in
the
past
we
just
avoided
that
with
open
telemetry,
because
it
seemed
very
invasive
right,
like
we
didn't
want
to
put
open
telemetry
in
a
position
where
we
said
as
soon
as
you
as
soon
as
you
add
this
open,
telemetry
instrumentation
here
it
like
breaks
the
stuff
receiving
the
message
over
there.
Does
that
make
sense.
E
Yeah,
I
think
the
the
I
think
one
goal
here
also
of
this
two
layer
model
and
also
the
cloud
events
model-
is
that
you
have
this
one
transportation
layer
and
basically
that
is
even
any
kind
of
message.
Diagnostic
system
understands
that,
because
that's
the
standard,
kind
of
trace
context
propagation,
also
with
hdb
that
goes
through.
E
So
any
kind
of
any
kind
of
non-message
of
their
component
kind
of
can
use
and
work
with
this
context,
and
then
you
have
this
application
context,
and
only
when
you
are
kind
of
a
messaging
system,
you
know
how
to
extract
this
context
and
how
to
use
it.
B
B
If
it's
just
a
json
structured
event,
then
it's
fine,
but
you
can
also
send
in
binary
and
then
in
that
case
you
would
need
to
deserialize
the
binary
blob
data
to
be
able
to
read
the
the
the
trace
context,
and
maybe
that's
not
also
good,
all
the
time
right
so
having
the
this.
This
is
somewhere
also
that
you
don't
need
to
ex
to
serialize
the
the
binary
cloud
event,
and
it's
also
it's
probably
also
necessary.
B
I
mean
it's
it's
it's
good
that
is
inside
already
and
then,
if
you
pass
this
to
a
broker
or
something,
then
it
knows
it's
a
called
event
that
it
can
deserialize
or
if
it's
just
json,
then
you
can
just
peek
into
that
property
individual.
But
if
it's,
if
it's
packed
into
a
different
format
like
binary,
then
you
only
hope
it's
to
deserialize,
and
I
don't
think
people
will
like
that.
Probably
right
so
having
this,
for
example,
indescending
in
in
http,
you
can
send
in
json
form,
but
you
can
also
save
in
binary
and
then
yeah.
B
F
Yeah
I
mean
if
you
have
binary
structure
right
like
if
your
binary
format
is
structured,
where
you
know
where
the
header
portion
should
be.
You
don't
have
to
deserialize
the
whole
message.
That's.
F
B
F
Yeah,
I
also
realize
it
we're
kind
of
it's
actually
kind
of
like
both
ways
have
problems.
If
we
shove
this
information
into
the
message,
then
the
the
consumers
and
receivers
need
to
be
aware
that
that
information
is
there.
If
we
put
it
into
the
transport
headers
of
any
form,
then
the
brokers
need
to
be
aware
that
that
information
is
there
right,
otherwise,
they're
just
going
to
drop
the
information
on
the
floor,
like
is,
I
think,
I'm
correct
in
saying
that
right,
like
yes,.
F
B
If
we
come
up
with
a
header,
for
example,
for
for
like
for
m2p
and
mqtt
like
like
johannes,
is
doing
with
the
with
the
w3c,
but
for
http,
I
I
think
we
yeah
like
if
we
use
the
condensed
one,
I
don't
think
so,
but
if
we,
if
we
use
this,
we
will
have
to
come
up
with
one.
That
is
like
a
standard.
So
then
everybody's
is
aware
of
it.
It's
like
a
standard
again
and
then
we
should
be
fine,
because
then
they
can
just
say.
Okay
do
I
have
something
here.
B
I
know
because
if
we
have
like
our
cloud,
events
is
c
whatever,
and
then
this
other
is
other
than
there's
a
mess
again
right.
So
yeah.
A
C
Can't
speak
to
sorry,
I
can't
speak
to
every
broker,
but
I
can
say
for
the
solace
broker.
I
mean
we
do
implement
http,
mpcd
and
mkp
for
all
of
those
protocols.
If
we
don't
understand
the
header,
we
attempt
make
every
effort
to
transport
those
opaquely
so
for
the
concept
of
putting
a
creation
header
in
an
http
header
that
the
broker
didn't
care
about,
because
we
only
kind
of
care
about
the
lowest
level
current
trace
context.
C
I
don't
think
that
would
be
a
problem
for
us
like
we
would
carry
it
through
and
it
would
remain
there.
But
I
don't
know
if
that's
generally
true
for
other
brokers
or
if
other
brokers
take
a
different
approach.
E
I
mean
for
talking
just
about
the
messaging
specific
protocols
I
mean.
Amqp
gives
you
certain
guarantees
current
is
there
I
mean
mqb
is
something
I
think
it's
called
user
properties
or
application
properties
which,
basically
by
mqb
definition,
is
like
a
read,
only
property,
that
the
broker
must
not
change,
and
it
must
be
passed
on
to
the
to
the
receiver
of
the
message-
and
I
think
mqtt,
I'm
not
sure,
but
think
has
something
similar.
So
those
protocols
kind
of
provide
means
to
kind
of
cover
for
those
scenarios.
E
C
C
The
clear
distinction
between
properties
and
annotations
like
amtp
does
amtp
has
fixed
things
that
the
broker
cannot
change
and
then
there's
message
annotations,
which
the
broker
can
add
and
the
spec
describes
using
both
of
them,
and
so
I
think
you
just
have
to
change
the
semantics
and
meanings
of
some
of
those
things.
Mqtt,
I
think,
is
more
like
am
htp
than
it
is
like
amtp,
I
think,
but
so
I
think
some
thinking
needs
to
apply
to
both
of
those.
E
I
mean
to
to
come
back
to
the
to
the
channel
problem.
We
we
faced
here
so
even
for
the
basic
basics.
When
we
talk
about
these
two
layers,
I
mean
I
always
make
the
experience
that
when
I,
when
one
talks
to
messaging
folks
about
that
they
say-
oh
yeah,
these
two
layers
definitely
make
sense.
E
We
need
that
when
one
shows
this
to
observability
people
who
don't
know
much
about
messaging,
everybody's
confused
and
doesn't
really
and
and
and
kind
of
says,
what
is
that
these
two
layers,
two
contacts
throwing
around
I'm
lost
here,
so
I
I
wonder,
ted.
What
do
you
think?
What
would
be
the
best
way
to
kind
of
just
double
check
us
here?
E
Should
I
bring
this
up
in
a
in
a
spec
meeting
and
kind
of
present
that
or
would
you
bring
it
up
like
in
probably
in
like
a
tc
meeting
to
to
just
make
sure
that
we
are
not
working
like
on
wrong
assumptions
here
and
that
later
on,
then,
when
we
have
the
autobrady
people
say?
Oh
no,
this
basic
context,
propagation
premises.
You
have
that
just
doesn't
make
sense.
F
I
think
prototyping
is
probably
the
best
solution
here.
We
in
every
point
in
the
past,
in
open,
telemetry,
open
tracing
where
part
of
trying
to
resolve
something
is
like
everyone's,
like
a
little
confused
about
the
model.
It's
certainly
context.
Management
within
programs,
for
example,
is
another
place
where
this
really
came
up.
F
We
were
talking
about
scopes
and
context,
switching
and
stuff,
and
how
do
you
model
that,
just
having
prototypes
that
people
can
look
at
help
quite
a
bit,
and
I
think
it
might
clear
some
things
up
for
for
certainly
would
clear
things
up
for
me.
If
I
could
see
you
know
a
working
prototype
for
some
of
these
models,
then
I
would
at
least
know
like
okay,
whatever
weird
concern
I
have
about
this
message
head
or
not
getting
through.
E
D
F
F
So,
having
like
a
working
prototype
or.
F
That
doesn't
work,
and
we
can
point
to
like
a
problem
where
it's
like
this
doesn't
work
right
now,
because
where
am
I
supposed
to
put
this
information
in
this
prototype,
that
would
be
really
helpful
and
then
diagrams
that
that
make
the
the
model
clear
for
people
if
we
make
a
presentation
with
those
those
items
at
the
spec
meeting
and
make
sure
that
tc
people
show
up
to
that
thing,
I
think
that
would
be
the
best.
F
Yeah
and-
and
I
think
we
we-
we
need
to
figure
out-
maybe
this
so
I
should
say
like
this-
isn't
just
a
messaging
group,
I'm
seeing
this
come
up
a
lot
right
now,
because
what
we've
done
is
we've
split
specification
development
out
into
a
number
of
different
groups
and
those
groups
all
contain.
F
You
know
a
lot
of
like
specialists
for
for
that
area,
but
don't
aren't
like
heavily
populated
by
like
tc
members
and
core
people,
so
the
the
rum
client
group,
for
example,
is
another
one
where
they've
kind
of
like
hit
this
point.
Where
going
going
it's
starting
to
get
a
little
frustrating
going
forwards
because
they've
done
all
this
modeling
and
then
when
they
take
it
back
to
the
tc,
they
get,
they
get
a
surprising
answer
from
them
around
something
or
other
so
figuring
out
the
best
way
to
to.
F
F
There
needs
to
be
a
way
to
to
bring
this
stuff
back
and
have
the
you
know
core
group
pay
attention
to
it,
rather
than
like
the
issue
right
now,
I'm
seeing
is
stuff
like
we're
doing
here
where
it's
like
we
just
kind
of
like
pop
up
with
a
pr
or
an
issue,
and
we're
saying
like
change
this
thing
or
add
this
thing,
and
since
the
people
on
the
other
side,
don't
have
like
a
bunch
of
context
about
where
we're
coming
from
the
the
discussion
gets,
gets
a
little
confused.
F
The
the
rum
group
had
a
similar
thing
around
they're
saying
like
we
don't
want
to
have
server,
name
and
server
version,
because
these
things
aren't
servers
they're,
they're
apps,
so
we
want
to
call
it
app
name
and
everyone
on
the
other
side,
freaked
out
and
said
no
and
then
so,
I'm
trying
to
like
resolve
that
that
little
knot.
So
it's
not
just
here.
E
Yeah,
okay,
so
I
will
pick
this
as
an
action
item
so
just
that
we
can
kind
of
ensure
that
we
have
like
a
backing
of
the
wider
community
for
this
context,
generation
model
that
we
are
coming
up
here.
E
Yes,
definitely,
and
I
think
it
would
kind
of
really
had
a
buzzwork
to
be
necessary
for
this
links-
discussion,
yeah,
yeah,
yeah,
okay,
so
yeah
so
much
for
context
propagation.
So
I
I
mean
I
put
done
in
front
of
the
basics
here.
I
will
actually
leave
this
here,
maybe
at
like
a
little
question
mark,
because
I
think
for
us
we
kind
of
in
this
group
we
more
or
less
agreed
on
this
two-layer
model.
E
It's
just
like
for
us
to
double-check
whether
this
makes
sense
for
other
people
too
and
yeah
I
mean
if
it
makes
sense,
then
I
think
we
can
take
it
as
we
sketched
it.
Currently,
if
not
yeah,
that's
the
question
mark,
then
we
need
to
revisit
that
here
and
then
also
this
here
as
a
consequence
for
the
next
point
of
producer
instrumentation,
we
did
not
really
start
talking
about
that
in
detail.
E
I
mean
we
know,
there's
a
creation
context,
some
somehow
there
must
be
a
great
span,
but
we
don't
yet
kind
of
know.
Is
that
what's
the
duration
of
this
create
span,
when
is
that
spank
created?
Is
that
created
can
be
created
by
like
an
messaging
sdk
or
next
is
created
by
the
user?
So
I
I
think
there
is
still
some
discussion
needed
here,
so
I
don't
put
any
any
done
here.
So
I
think
this
is
still
a
discussion
that
we
need.
D
I
want
to
ask
we
keep
talking
about
scenarios
where
we
do
a
batch
message
produce
and
I
consume,
but
there
are
a
lot
of
use
cases
where
it's
just
one
to
one:
okay,
like
task
queues
or
stuff
like
that
that
you,
you
call
a
function
and
it
pushes
it
into
radius
and
then
a
walker
fetches
it
on
the
other
side,
and
I
think,
for
those
cases.
D
Think
if
this
create
span
and
all
our
model
works
well,
because
it
could
be
a
little
too
complicated
to
model
very
simple
things
like
just
someone,
is
creating
a
message
and
the
worker
is
touching.
It.
C
D
C
E
Definitely,
yes,
that's
that's
why
I
say
there
is
still,
I
think,
discussion
here
to
be
done
and
I
think
we
didn't
really
discuss
about
that
at
all.
I
think
we
all
have
some
assumptions
about
this
creation
context
and
creation
span,
but
I
think
there's
quite
some
question
marks
around
that
as
amir
pointed
out,
so
I
think
we
should.
There
is
still
like
as
a
discussion
needed
here.
E
We
we
discussed
quite
a
bit
about
the
consumer
instrumentation,
also
thanks
to
like
some
pre-work
that
amir
and
arthur
ludmilla
did
so.
We
have
those
push
scenarios
where
we
kind
of
will
use
this
the
liver
span.
That
is
a
part
that
is
already
in
this
other
draft,
where
basically,
the
application
gives
the
callback
to
the
to
this
messaging
sdk
and
then
the
messaging
sdk
calls
the
callback
with
a
single
message
or
batch
of
messages.
E
That
is
what
we
have
currently
kind
of
written
out
in
the
draft,
so
we
have
some
results
there
that
when
some
details
might
still
be
open
but
like
in
the
rough
we
kind
of
converged
on
that
and
last
week
we
were
talking
about
those
pool
scenarios.
Basically,
when
the
when
the
consumer
calls
like
a
receive
method
and
receives
a
single
span
or
a
batch
of
spence
and
yeah,
that
is
the
discussion
in
progress.
Also
with
the
linking.
E
I
think
we
have
a
preferred
solution
here
that
ludmilla
presented,
but
we
don't
know
yet
whether
we
can
use
it
because
of
those
limitations
of
adding
links.
So
here
this
is
still
in
progress
and
there
is
ongoing
discussions
about
that.
But
I
think
in
the
the
rough
solutions
we
have
here,
I
I
think
look
pretty
good
to
me
or
says:
army
brought
up
like
the
problems
about
batching
and
I
think,
with
those
two
solutions
we
have
here.
E
We
very
well
cover
like
cases
with
batching
and
cases
without
batching,
and
I
think
you
also
have
a
pretty
powerful
solution
here,
because
this
deliver
and
receive
span
can
be
automatically
created
by
which
is
very
nice.
So
we
don't
need
any.
E
We
wouldn't
need
any
instrument
instrumentation
in
for
the
actual
sdk
users,
and
that
can
easily
be
extended
by
just
adding
process
bands
on
the
application
code
site,
but
it's
not
necessary.
The
process
bands
are
not
necessary
for
having
kind
of
the
the
linking
or
the
connections,
because
those
are
in
the
deliverance
receive
spans,
so
that
kind
of
for
the
consumer
instrumentation,
it
seems
to
me
we
are
like
converting
to
a
pretty
nice
and
powerful
solution
here.
E
What
is
still
open,
but
we
didn't
yet
talk
about
the
settlement
in
how
far
we
want
to
support
instrumentation
for
settlement
and
how
that
looks
like
so
that,
I
think,
is
still
something
we
need
to
discuss
in
this
group.
That's
an
open
issue
and
then,
as
a
last
point,
the
others
also
here
we
need
to
discuss
about
the
attributes,
general
attributes
and
then
also
your
system,
specific
attributes,
I'm
not
sure
how
much
discussion
we
will
need
there.
E
E
So
those
are
all
things
that
we
would
need
to
consider
when
working
when
working
through
this.
I
also
know
that
the
amir
did
some
work
there
already
also
thinking
about
attributes
and
links,
so
I
I
think
this.
This
will
also
need
some
discussion,
whether
we
kind
of
decide
to
go
the
drought,
how
we
gonna
use
those
attributes
and
appear
what
we're
going
to
do
there.
E
So
that
is
the
last
point
here
on
my
list
of
open
discussion
items
and
I
think,
when
we
came
to
like
come
to
some
agreement
on
all
of
those
points,
I
I
think
we
are
ready
kind
of
to
finish
this
out
tap
and
put
it
up
and
then
get
some
by
the
agreement
and
approvals
and
then
yeah
merge
it
into
this
back.
Hopefully,
I'm
not
sure
if
any
of
you
sees
any
kind
of
further
items
that
you
think
need
to
be
discussed
and
that
are
missing
in
this
list
this
list.
Basically
it's
a.
E
E
So
if
I
just
try
to
kind
of
restrict
this
to
points
that
we
need
to
discuss
in
this
group
and
come
to
an
agreement
too,
and
they
are
not
sure
if
there's
any
things
that
that
you
are
that
you're
missing
here,
that
you
would
like
to
have
discussed.
C
I
have
one
thing
I'm
wondering
about:
I'm
not
sure
if
this
falls
into
the
category
of
it's
primarily
concern
of
the
intermediary
and
therefore
not
in
scope
or,
but
just
I
think,
we've
touched
on
in
the
past,
where,
if
a
broker
persists
a
message
and
delivers
it
later
that
it
may
be
a
good
idea
to
split
that
into
two
traces,
because
having
a
trace
go
on
for
a
day
can
be
problematic.
C
Is
that
something
that
we
think
this
spec
should
prescribe
in
any
way
or
because,
even
if
we're
not
talking
about
broker
instrumentation,
maybe
without
brokers
being
involved
at
all
in
instrumentation,
that
there's
still
a
problem
between
the
producer
and
consumer
that,
even
if
the
broker
doesn't
add
spans
or
participate
in
the
trace
that
this
disconnect
can
happen?
And
how
should
that
be
handled?
E
That
is
a
good
question
I
mean
in
in
my
head.
It
definitely
is
kind
of
an
implicit
assumption
that
I
have
that.
E
The
the
that
the
the
trace,
the
the
producer
trace,
like
the
producer,
basically
cars
into
the
intermediary-
and
maybe
the
intermediary-
continues
the
trace
there-
that
this
trace
can
and
will
in
many
instances,
be
different
from
the
consumer
trace
like
when
the
media
records
back
into
the
consumer
and
the
consumer
kind
of
continues
the
trace
from
the
intermediary
that
those
will
be
or
can
and
really
many
instances
be
two
different
races
and
not
the
same
trace.
E
So
that's
kind
of
it's
an
implicit
assumption
that
I
have
in
my
head,
but
it's
a
good
point.
I
think
we
should.
We
should
maybe
discuss
those
and
make
this
explicit.
C
And
one
thing
where
it
could
be
confusing
a
little
bit
is
if,
if
the
broker
doesn't
participate
in
the
trace-
and
it
just
transports
the
trace
context
transparently
and
the
consumer
receives
it,
how
does
the
consumer
know
if
the
broker
participated
in
that
trace
and
whether
this
is
a
consumer
trace
or
if
this
is
the
context
from
the
producer,
because
that
might
indicate
whether
they,
the
consumer,
wants
to
link
to
that
context
or
if
they
want
to
be
a
child
of
that.
C
E
E
E
I
think
you
can
easily-
I
mean
here
also
this.
Actually
these
two
models,
this
two-layer
approach,
helps
us
here,
because
if
the
intermediary
or
the
broker
is
not
instrumented,
then
the
consumer
will
not
receive
any
transport
context,
because
a
broker
that
is
not
instrumented
will
not
pass
on
any
transport
context.
E
That
that
would
be
basically
the
the
case
for
the
creation
context,
so
the
producer
would
attach,
like
some
context,
to
the
message
and
the
the
consumer
would
then
receive
the
message
and
also
this
context.
That
would
be
the
creation
context,
and
in
that
case,
if
the
intermediary
is
not
instrumented,
then
basically
the
consumer
doesn't
receive
any
transport
context
from
the
from
the
broker.
E
C
E
I
think
that
is
yet
that
that's
something
we
have
to
discuss
here.
C
Yeah,
I
think
if
there
is
a
producer
span,
that's
where
I
think
this
gets
tricky.
If
there's
only
one
span
before
a
message
ever
gets
sent,
then
then
I
I
don't
think,
there's
a
concern,
but
if
there
is
both
a
create
and
produce
span,
then
I
think
we
may
be
talking
about
getting
into
three
layers,
which
sounds
crazy
or
I
guess
to
be
avoided
if
possible
and
yeah.
So
so
I
think
we
have
to
maybe
decide
on
that
first
before
we
could
have
this
discussion
yeah.
So.
B
For
example,
if
the
sdk
that
you're
using
to
interact
with
the
broker
or
the
messaging
system
is
instrumented,
then
you
will
create
the
so
like
the
user,
for
example,
will
create
the
create
context.
Let's
say
that
the
user
is
responsible,
so
you
have
one
trace
and
then
after
it's
actually
sent
so
the
sdk
is
instrument.
Then
you
have
the
publish
because
the
sdk
does
and
then
this
message
gets
to
the
broker
and
then
let's
say
the
broker
is
also
instrumented.
B
Then
it
will
know
that
it
receive
a
publish
spam
context
from
someone
else
will
continue
the
trace
and
then
send
to
the
consumer
also
creating
its
own.
That's
the
I
don't
know
push
or
something,
and
then
when
the
this
message
receive
arrives
at
the
consumer
and
then
it
comes
okay.
I
already
have
a
remote
trace
that
be
they
came
from
the
broker
and
then
that
will
just
continue.
So
then
they're
the
consumer
will
create
a
new
span
that
has
a
parent
of
the
span
created
by
the
broker.
B
So
they
don't
have
like
three
like
to
continue
so
so
yeah.
It
depends
if
they
are
instrumented
so
yeah.
C
I
think
that's
easier
to
understand
to
me.
The
complication
comes
in
if
the
producing
sdks
is
instrumented,
and
so
you
have
a
create
span
and
a
span
for
the
push.
Yes
and
then
the
broker
doesn't
instrument
right
and
then
it
pat
the
broker
passes
that
span
through
to
the
consumer.
C
And
then
the
consumer
receives
a
span
context
which
it
doesn't
know
if
that
was
the
broker's
span
from
from
the
it's
send
or
whether
it's
the
producer
span.
B
Yeah
no,
but
it's
fine,
because
if,
if
if
this
case
that
you
just
described
happened
like
the
broker
is
not
instrument,
then
the
receiver
will
not
receive
anything.
There
will
be
no
nose
fans
coming
from
the
from
the
broker.
B
It's
not
gonna,
remove
it's
just
it's
not
gonna
gonna
propagate
it,
so
the
the
producer
will
send
the
published
span
like
both
spans,
but
it
doesn't
know
what
to
do
with
it.
So
it
would
not
continue
or
like
will
not
propagate
it,
so
the
receiver
will
not
receive
it.
So
it's
it's
as
as,
if
never
happened
or
he's
not
aware
of
it.
C
Yeah
it
just
I
don't
know
if
that's
ideal
behavior,
because
it
would
be
good
for
a
consumer
to
say
hey.
There
is
a
span
over
here
that
that
that
the
producer
created,
I
should
link
to
it
and
and
connect
these
things
together,
and
I
mean
to
me
that
seems
better
than
saying
well,
because
the
broker
didn't
instrument
anything
that
this
potential
to
link
to
the
producer
is
lost.
B
B
C
E
E
So
when
you
receive
this
mqb
message
on
the
on
the
consumer
side-
and
you
look
at
this
transport
context,
you
do
not
know
whether
this
transport
context
is
from
the
intermediary
from
the
broker
and
the
broker
was
instrumented
or
the
broker
was
not
instrumented.
Then
the
broker
left
this
context
from
the
producer
intact.
E
I
think
that
is
the
case
that
duane
is
referring
to
yeah
exactly.
We
definitely
should
discuss
those
cases,
and
so
it's
good
that
we,
I
added
this
point
here
with
intermediate
instrumentation
and
with
the
different
consumer
producer
traces
so
that
that's
that's
a
good
call
out.
You
should
also.
E
And
I
also
see
it
is:
this:
prototype
might
help
us
here
right
to
visualize
and
kind
of
get
get
the
grasp
on
that.
B
Because
I
was
under
the
impression
if
the,
if
the,
if
the
broker
or
the
intermediaries
is
not
instrumental
or
if
it
even
if
it
is
instrumented,
it
will
just
create
a
new
one.
You
spend
like
like
it
would
be
in
http,
but
yeah.
B
E
So
for
this
discussion
items,
if
anything
comes
to
your
mind,
feel
free
to
to
extend
this
list
also.
I
also
I
I
will
then
for
the
next
basically
protocols.
I
will
just
copy
this
over
and
we
can
update
this
and
also
for
those
open
issues.
E
If
you
have
some
free
cycles
to
think
about
any
of
those,
please
feel
free
to
just
pick
one
of
those.
It
was
really
like
a
amazing
help,
just
amir
and
luke
miller,
picking
issues
here
and
on
their
own,
like
working
on
them
and
proposing
solutions.
So
if
you
have
some
cyclists
to
do
that,
that
would
be
awesome
and
speeds
us
up
a
lot
otherwise
yeah.
I
will
try
to
get
the
prototype
working
here
and
maybe
then
we
can
gain
some
insights
from
that
and
be
able.
B
To
have
one
prototype
already
that
I
worked
for
cloud
events
but
for
http
for
links,
so
maybe
I
can
send
you
or
I
don't
know
I
I
can
I
can.
I
can
reach
to
you
on
slack
afterwards.
Yeah.