►
From YouTube: 2021-12-09 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
B
C
A
C
B
C
Yes,
we
can
time
box
it
because,
let's
see
what's
on
the
gender
and
depending
on
that,
let's
time
box,
but
be
great,
if
you
could
start
us
off
sure.
D
C
E
E
C
C
C
E
D
Hopefully,
dwayne
will
be
arriving
shortly.
B
Yes
cool
so
last
week
we
started
talking
about
this
document
where
I
summarized
my
experience
with
working
on
messaging
systems,
specifically
in
birch
receive
scenarios.
So
I
have
all
the
scenarios
here
and
I
made
some
changes
and
added
few
more.
I
don't
think
we
need
to
look
at
them
again.
It's
in
the
dock
and
feel
free
to
take
a
look,
and
the
thing
that
I
did
added
was
this
section
about
the
ambient
context,
so
it's
very
similar
to
the
previous
ones.
B
B
But
I
think
it's
very
interesting
to
er
to
review
the
various
ways
that
we
can
settle
a
message
and
discuss
how
we
want
this
to
be
represented
in
a
spec,
whether
it's
a
new
span
or
whether
it's
something
that
we
attach
to
some
other
spam
and
multiple
ways
of
doing
it.
For
example,
a
batch
checkpoint
settlement,
the
semantics,
if
you
want
to
add
links
on
it
or
spin
attributes,
so
where
these
are
all
things
that
I
believe
we
need
to
talk
about.
B
Also,
we
need
to
talk
about
the
ambient
context
and
walking
traces.
I
think
make
sure
that
our
solution
works,
even
if
there
is
a
problem
in
the
trace
that,
for
some
reason
something
is
not
connected
to
something
else
is
expected
which,
for
my
experience,
it's
a
real
world
problem.
B
These
are
all
small
topics
that
I
don't
want
to
discuss
now,
but
I
wrote
them
here,
so
we
can
think
if
we
want
to
discuss
them
later,
when
we
talk
about
the
specifications
or
like
to
get
your
feedback,
how
you
think
it's
better
to
be
handled
and
okay,
so
so
that's
all
about
the
overview,
and
now
I
want
to
ask
you
if
you
think
it's
if
we
want
to
read
these
suggestions
and
discuss
them
and
like
back
them
up
with
the
scenarios
below,
maybe
you
have
some
things
to
some
thoughts
on
on
it
or
some
suggestions.
C
I
I
think
I'm
raped.
I
definitely
would
like
to
focus
on
this
batch
receive
scenarios
that
we
started
last
time,
and
maybe
then
we
can
see
whether
this
single
message
receive
is
maybe
can
just
be
modeled
like
as
a
subset
of
those
scenarios
like
with
the
same
with
the
same
modeling
that
you
came
up
with
for
the
batch
stuff.
I
wonder
if
maybe
you
could
just
shortly
highlight
what
is
the
basically
the
commonality
in
terms
of
span
structure
across
all
the
scenarios
that
you
came
up
below?
C
B
Yeah,
so,
regarding
batching
scenarios,
I
agree
with
you
that
I
believe
there
should
be
a
safe
span
every
time.
Currently,
the
current
spec
does
not
require
a
safe
span.
If
it's
a
one-to-one
relations,
if
you're
fetching
a
one
message
entering
one
message
at
a
time,
which
is
something
I
believe
we
can
talk
on
the
single
message
process
topic,
I
do
I
like
to
discuss
most
of
these
suggestions.
The
regarding
links
like
which
links
should
we
place
well,
and
why
like?
B
What
are
the
use
cases
that,
if
we
don't
have
this
link,
we'll
get
stuck
with
the
trace
that
we
can't
connect
together
like
multiple
fragments
of
traces
that
will
not
be
able
to
to
get
the
whole
story
from
start
to
end?
And
so
a
lot
of
them
are
about
the
links
and
what
we're
expecting
the
relationships
between
spans,
like,
for
example,
between
a
process
and
the
receive
spam
like
how
how
they
are
allowed
to
be
composed
together
and
which
scenarios
might
be
problematic.
B
So
maybe
I'll
just
start,
and
we
see
how
it
goes.
And
if
you
see
that
you
want
to
stop
or
change
the
format,
then
let
me
know.
C
B
So
this
is
how
it
looks
like
it's
not
a
final.
Yet
it's
like
a
document
that
I
work
on.
Not
everything
is
documented
and
there
are
no
graphs
and
code
snippets
for
all
cases.
B
I
do,
I
would
like
to
add
them
in
the
future
or
maybe,
if
someone
wants
to
join
and
help
on
this
document,
you
are
very
welcome,
and
so
this
is
how
it
looks
like
I
have
multiple
scenarios
here,
for
example,
this
is
like
maybe
the
canonical
scenario
for
a
processing
of
a
batch
receive
where
we
have
a
safe
span
under
the
receive
span.
We
have
two
processing
spans.
B
D
B
Yeah
you're
right,
I
need
to
write
it
down.
The
black
arrow
is
a
parent-child
relationship
between
spams
arrows
are
links
to
some
other
span,
maybe
in
the
same
twas,
maybe
in
some
other
trace.
So
what
we
see
here
is
that
the
process
spans
of
the
child
of
the
receive
and
they
have
the
link
to
the
create
spam.
This
is
the
span
that
sent
or
published
or
pushed
the
message
into
the
queue
into
the
messaging
vocal
color.
A
Yeah,
thank
you.
I
have
a
question
about
the
relationship
between
receive
and
process.
I
don't
think
it's
always
feasible
to
make
receive
a
parent,
because
I
can
write
my
code
in
a
way
that
okay,
I
received
10
messages
and
then
I
start
processing
them
and
the
receive
span
has
ended
by
that
time.
B
There
you
are,
I
have
this
section
here.
I
hope
it's
not
small.
Let
me
enlarge
it
a
bit,
so
I
have
this
section
here
that
describes
the
possible
relationships
that
I
could
come
up
with
regarding
a
process
received.
A
B
Yeah
yeah,
so
so
this
scenarios
they
describe
multiple
possible
scenarios
that
I
saw
in
productions
in
in
our
system
and
in
our
clients
systems.
So
this
is,
of
course,
the
most
easiest
diagram
of
our.
We
imagine
a
receiving
process
suspense,
but
of
course,
it's
possible
to
have
other
cases
which
some
of
them
are
here
as
other
topics
in
this
document.
B
B
So
another
example
is
that
we
have
iterations
on
the
messages
array,
but
it's
not
like
the
first
day.
Iteration
is
doing
some
transformation
on
the
message
and
then
a
second
iteration
picks
it
up,
and
some
some
other
processing
and
another
example
is
that
we
have
no
processing
at
all.
This
is,
I
think,
the
most
common
one
in
all
the
cases
I've
seen
because
it's
really
difficult
in
the
in
real
world
cases
to
represent
or
auto
create
those
processing
spins.
B
B
B
So
this
is
one
example
of
the
scenarios
and
there
are
other
examples
here
for
batch
operations
for
looping
styles,
there's
one
for
this
creation
of
the
process
span,
which
might
be
missing.
So
this
is
discussing
adding
some
utility
or
some
rapper
or
some
decoration
in
the
user
code.
If
he
chooses
to
to
enrich
his
trace
and
recreate
this
lost
process
span
and-
and
I
have
a
section
about
the
create
context-
it
might
be
absent-
maybe
something
happened
to
the
context,
propagation
and
another
one
for
ambient
context.
C
But
just
to
summarize
I'm
here,
thank
you
for
want
to
kind
of
extract
like
the
common
points
here
is
that
yeah
we
always
have
a
receive
span,
and
this
receives
span
always
links
to
the
creation
contexts
to
the
creation
span.
So
that's
what
we
have
in
all
the
cases
and
then
basically
the
other
thing
is
that,
if
possible,
this
receives
span
somehow
correlates
then
to
the
processing
related
to
those
bands
that
can
be
by
a
process
then,
but
it
also
can
be
in
some
other
way
that
we
basically
don't
have
dedicated
process
bands.
D
B
So
I
think
that
the
send
belongs
to
this
section,
take
all
these
scenarios
and-
and
then
like
do
another
section
that
talks
about
the
nice
ways
to
send
messages,
and
there
are
also
a
few
cases
in
this
area
from
my
experience,
so
I
I
would
like
to
discuss
it
in
the
future.
C
Here,
I
think,
for
I
think
what
we
we
are.
I
think
I'm
just
talking
about
the
consumer
side
here,
but
what
we
see
in
regard
like
to
create
and
send
basically,
we
only
have
from
from
the
consumer
side.
We
only
have
basically
a
link
to
the
creation
context
like
to
the
create,
but
we
don't
have
a
link
to
the
send.
C
Yes,
partly,
but
I
think
another
reason
is
that
the
scent
might
not
be
relate
to
like
one
individual
message.
I
think,
with
the
creation
context,
we
can
also
the
discretion.
Context
also
always
relates
to
a
single
message,
but
the
send
context
like,
for
example,
we
can
just
send
the
bug
a
batch
of
messages.
The
same
context
not
necessarily
refers
to
to
a
single
message.
D
C
I
think
what
amir
is
presenting
here,
that's
mostly
on
the
application
layer.
I
think
where
the
infrastructure
layer
could
come
into
place.
That
is
this
ambient
context
that
he
talks
at
the
very
end
like
this
ambient
context.
That,
for
example,
could
derive
from
some
infrastructure
layer
that
then
kind
of
that
then
links
back
to
the
intermediary.
C
A
Mind
I
you
mentioned
that
you
can
put
things
that
happen
for
processing
on
the
receive
operation
like
database
calls,
I'm
interested
how
how
could
it
be
or
how
it
could
happen
that
receive
call
continues
into
the
database
course.
The
span.
B
Yes,
so
a
very
common
pattern
for
a
message
processing
is
that
you
are
doing
a
receive
operation.
This
receive
operation
might
return
multiple
messages
and
at
least
in
the
node.
It's
you
probably
you
most
of
the
time
you
get
an
array
of
messages,
and
then
you
can
do
whatever
you
want
with
this
array.
B
So
here
we
we
perform
a
receive.
We
get
back
a
response.
This
response
has
an
array
of
messages,
and
then
we
can
start
calling
functions
on
this
array.
So,
for
example,
we
can
call
a
array
functions
like
mark
for
reach.
Filter
reduce
another
style
is
to
just
do
a
plane
for
each
ffo
loop
with
the
index,
or
we
have
the
index
running
from
zero
to
the
length
of
the
array,
and
then
we
just
reference
each
message
and
do
some
operations.
B
Another
style
could
be
a
some
a
terato,
for
example,
in
javascript.
We
can
write
a
forward
message
of
messages
and
so,
except
for
the
one
for
the
first
case,
where
I
was
able
to
to
solve
it
automatically.
B
If
the
user
is
just
referencing,
this
messages
array
by
index
and
then
he
fetches
a
message,
and
he
takes
this
message
and
write
it
to
the
database.
So
in
this
case
it's
impossible
to
automatically
create
the
process
pins.
We
will
just
see
this
database
access
span
as
a
direct
child
of
the
active
spend
in
this
case,
which
is
the
receive.
A
B
Yeah,
so
it's
very
interesting
topic
on
its
own,
like
how
do
we
scope
the
receive
span?
So
if
the
receive
span
has
some
callback
and
it
invokes
the
callback,
so
things
are
very
easy,
but
unfortunately,
this
pattern
of
async
awaits
it
makes
things
much
harder
in
javascript
at
least,
and
I
don't
know
how
it
goes
in
other
languages
that
have
this
mechanism.
B
I
would
like
to
to
know
to
hear
your
experience
if
you
have
something
to
share
about
it,
but
you're
right,
it's
it's
also
very
difficult
to
scope.
The
receive
operation
correctly,
and
this
is
part
of
the
reasons
why
traces
break
so
we
have
the
receive
and
some
other
operations
which
should
be
the
child
of
the
received,
but
unfortunately
they
start
with
their
own
fresh
trace
yeah.
So
your
comment
is
right
about.
C
I
mean
I
mean,
I
think
I
I
wonder
if
those
processing
spent
should
even
be
children
of
receive,
because
I
mean
the
receive,
has
a
duration
and
then
also
processing
has
a
duration
and-
and
I
think
the
processing
duration
is
not
part
of
the
received
duration.
Usually
so
maybe
they
should
be
like
separate.
C
They
should
not
be
like
a
parent
child,
and
I
wonder
if
it's
just
sufficient
for
users,
if
they're
just
like
I
mean
in
your
example,
it
would
be
easy
to
make
them
siblings,
like
they
shared,
they
would
share
the
same
parent
and
they
put
basically
siblings
next
to
each
other,
and
I
wonder
if
that
would
be
actually
enough
of
a
correlation
between
process
and
the
receive
spans,
if
you
just
locate
your
siblings,
of
course,
that
is
then
not
that's,
not
a
really
kind
of
them.
C
That's
not
a
correlation
that
makes
like
that
makes
this
correlation
like
unique,
uniquely
uniquely
identifiable,
like
you,
have
to
then
diffuse
from
context
how
they,
how
they
relate
to
each
other.
A
F
But
if
we,
if
we
can
find
a
way
to
to
like
use
the
processes,
then
to
link
the
each
individual
process,
then
it's
I
guess,
then
it
will
be
easier
to
kind
of
scope
it,
because
if
we
create
it
ourselves
right,
then
we
can
scope
it
easily
when
you're
processing.
The
message
in
your
example
that
the
for
loop,
for
example-
I
mean
they
receive.
I
think
I
think
I
agree
with
me
that
the
receive
it
will
end
as
soon
as
that
line
is
done.
F
But
then,
if
we
later
on,
we
offer
some
sort
of
hand
or
something
that
has
callbacks
or
something
that
the
process
processing
code
goes
in.
Then
then,
we
can
probably
easily
correlate
them
as
a
child,
and
then
we
can
use
the
processing
as
a
sibling
as
as,
as
johannes
said,
as
a
sibling
of
the
receive,
because
it
will
be
ended
anyway.
At
that
point,
so
can
be
a
child.
There.
B
B
I
agree
with
everything
that's
been
said.
I
think,
as
a
general
guidelines
like
current
specification
is
very
strict
about
the
way
that
the
messaging
relationship
between
tracers
and
links
and
their
various
and
others
it's
it's
like
saying.
A
B
Is
how
it
should
be,
and
that's
it,
but
when
you
start
to
actually
implement
these
things,
and
I
implemented
the
four-way
messaging
instrumentations
in
a
node.
So
there
is
the
specification
and
there's
a
an
ideal
model
for
how
we
would
like
to
see
things
like
instrumented
and
exported.
B
But
unfortunately,
when
you
start
really
doing
it,
then
you
hit
a
wall,
and
then
you
have
to
like
to
find
a
way
to
hack
around
the
specification
and
to
do
the
best
you
can.
So
I
would
really
be
happy
if
we
can
review
all
these
possible
complications
and
make
sure
that
the
final
specification
we
suggest
at
least
that
does
the
best
effort
in
supporting
all
these
use.
B
C
Yes,
I
like
that
approach,
and
I
mean
you
need
to
heart
back
for
what
miller
said.
I
think
what
we,
what
we
see
in
your
examples,
armor,
which
is
great,
is
that
basically,
this
this
common
denominator
that
we
have
is
basically
that
we
can
have
a
receive
span
and
then,
given
that
we
have
the
creation
context,
we
can
link
these
receives
by
into
the
creation
context.
That
is
basically
like
what
we
can
always
do
and
everything
else
is
more
or
less
best.
C
B
Yeah
yeah,
I
agree
with
it.
I
like
it,
so
we
only
have
five
minutes
left.
C
Time
frame
we
can
go
longer,
we
can
go
till
45
if
you
want
I'm
just
curious
about,
like
luke
miller's
opinion
on
that
kind
of
minimalistic
approach.
Do
you
think
that
is.
A
A
I
can
do
more
things
and
probably
we
can
provide
a
bit
more
than
bare
minimum
and
then
we
can
also
provide
some
apis
to
help
users
extract
context
and
start
dispense,
for
example,
so,
like
we
depend
on
users
and
we
should
document
and
provide
them
guidance,
but
I
like
this
idea
of
different
layers
of
support
and
clearly
documenting
them.
C
C
B
Cool,
so
let's
take
the
few
minutes
that
we
have
left
for
this
topic
and
maybe
just
read
one
or
two
of
these
points
to
so
you
can
give
me
feedback
on
if
you
think
it's
structured
correctly
or
if
you
have
more
comments.
B
So
the
the
first
note
here
is
that
the
receive
span
should
contain
links
to
all
the
create
spans
in
the
batch.
B
So
if
we
go
back
down
to
the
to
the
scenarios,
so
what
I'm
talking
about
is
this
blue
line
that
goes
from
the
receive
to
the
create
okay,
and
the
reason
that
I
suggest
to
add
this
link
is
we
all
agree
that
sometimes
the
processing
expense
can
can
be
absent
in
the
trace.
B
B
So
we
have
like
a
consistent
way
of
knowing
that
we
got
some
message
and
maybe
tried
to
handle
it,
or
maybe
we
handled
it,
but
we
didn't
able
to
we
weren't
able
to
create
the
process
span
and
it
also
gave
us
the
ability
in
the
in
the
presence
of
multiple
process
spends,
which
I
also
believe
is
something
that
we
will
have
to
do.
In
some
cases
it
gives
us
like
one
place
where
we
can
take
a
look
and
say:
okay.
B
These
are
all
the
messages
that
we
received,
like
all
sitting
on
a
single
span
without
the
need
to
reconstruct
the
trace
or
imply
some
extra
logic
on
aggregating
those
child,
their
processing
expense.
We
can
just
look
at
the
receive
and
say:
okay,
we
got
ten
messages.
These
are
the
messages.
Maybe
something
happened
with
them?
Maybe
not,
but
we
we
have
a
way
of
telling
this
information,
it's
also
very
handy
to
for
empty
receives,
which
are
something
that
can
also
be
very
common.
B
So
we
try
to
fetch
data
and
we
get
back
an
empty
array
of
messages
and
then
some
users
might
want
to
like
drop
these
traces
because
they're
not
very
interesting,
and
there
can
be
plenty
of
them.
So
it
makes
it
very
easy
to
do
this
thing.
Yes,
so
something
else
regarding
those
links.
So
it
is
possible
that
we
do
not
get
the
the
open,
telemetry
context
propagated
when
we
do
the
receive
so
we
can
force.
For
example,
we
can
do
bachelor
safe
get
back
here.
B
B
One
option
that
we
discuss
is
having
like
a
link
with
the
empty
context
like
all
zeroes,
or
something
to
to
a
signal
that
this
link
is
missing
some
data,
but
still
have
the
link.
So
if
we
got
10
messages,
then
only
five
of
them
have
the
the
link
to
the
creator
span.
So
we'll
still
have
ten
messages.
B
Five
of
them
will
have
valid
context
and
five
of
them
will
have
invalid
context,
and
another
thing
I
want
to
suggest
is
that
sometimes,
if
we
don't,
we
don't
have
the
link,
but
we
still
have
some
useful
data.
For
example,
the
message
id
like
some
id
that
the
message
messaging
system
uses-
and
I
want
to
suggest
to
add
this
to
the
link
as
well.
So
if
we
don't
have
the
context,
but
we
still
have
the
message
id
so
it
will
be
instrumented
and
exported.
B
B
B
And
yes,
so
it's
a
42
already,
and
I
want
to
ask
you
before
we
go
to
the
next
topic.
I
want
to
ask
you
how
you
think
we
should
proceed
with
this
because
we
meet
once
a
week
and
we
have
a
lot
to
talk
about,
but
I
would
really
be
happy
to
to
see
these
things
that
were
talking
about
start
start
to
see
them
written
down
and
have
maybe
some
ways
to
comment
to
comment
on
it
and
to
discuss
it
not
in
this
meeting.
B
So
what
do
you
think
should
be
the
best
way
to
continue
this
effort?
Maybe
for
the
time
that
we're
not
meeting
once
a
week.
C
I
think
the
best
way
to
continue
this
amir
is
there's
already
this
old
tap
up
regarding
like
regarding,
like
those
suspect,
changes
that
we
want
to
make,
and
I
think
the
best
thing
here
would
just
be
adding
like
adding
this
to
this
old
tap,
because
that
old
depth
that
is
kind
of
quite
visible
people
can
easily
comment
on
that
and
they
can
iterate
on
that.
C
So
I
I
think
with
this,
and
it
seems
to
me
today
we
have
some
kind
of
agreement
or
consensus
about
this
receive
span
that
you
that
you
suggested
here.
So
I
think
a
great
next
step.
Would
you
just
be
addis
to
the
adding
this
to
this
o
tap
as
part
of
this
of
the
basically
consumer
instrumentation,
I
mean
what
what
might
be
great
before
would
that
we
also
clarify
like
this
single
message
scenario
I
mean
I
would.
C
I
would
love
to
have
that
somehow,
consistent
with
the
batching
scenario,
for
example,
that
we
also
have
basically
this
receive
span
for
single
messages
scenarios,
but
I
I
think
once
once
we
have
that
figured
out,
I
think
we
are.
We
are
ready
to
basically
specify
the
consumer
instrumentation
in
this
old
tab.
F
Should
we
also
discuss
a
little
bit
your
comment
that
you
left
there
about
the
receive
having
to
deserialize
the
message,
because
that's
probably
kind
of
a
big
deal
as
well
now.
C
Yes,
that
that
kind
of
deals
or
that
beers
into
the
context
propagation
topic-
and
I
think
what
I
think
what
amir
suggests
here,
it
basically
presupposes
that
this
creation
context
can
be
read
without
deserializing.
The
message,
because
I
think
in
in
this
receive
span
that
that
of
that
mostly
happens,
I
think
in
sdks
and
I
think
the
sdks
usually
don't
deserialize
messages.
C
F
C
C
Event-
and
I
think
then,
for
those
scenarios-
basically,
it
would
be
hard
for
for
this
received
context
to
get
this
to
get
this
context
out,
because
they
would
to
have
to
deserialize
almost
the
whole
cloud
event
to
get
this
out.
So
that
is
just
something
that
we
would
need
them
to
clarify
in
our
context,
propagation
section.
B
It
might
be
because
it's
it's
really
not
there
like
there's
nothing
on
the
message
that
holds
this
information,
that
we
can
extract
and
touch
as
a
link,
but
it
also
can
be
because
it's
expensive
to
extract
it
and
we
don't
want
to,
like
the
user,
chooses
to
configure
his
instrumentation
in
a
way
that
we
do
not
extract
this
context
and
then
it
might
be
missing,
which
is
a
valid,
maybe
not
so
desired
scenario,
but
valid
scenario.
That
can
happen
in
multiple
cases.
C
Yeah
I
like
that
this
is
the
point
on
on
your
list
that
we
have
to
deal
with.
We
need
to
be
aware
that
we
need
to
deal
with
like
missing
creation
context.
B
Definitely
yeah
so
for
next
week
I
will
add
the
single
process
scenarios
and
if
somebody
wants
to
join
this
effort-
and
they
work
on
this
document
together
so
feel
free
to
reach
out
in
a
slack.
I
would
really
be
happy
to
to
share
this
work
with
someone
if
you're
interested
so
just
reach
out.
If
you
find
it
interesting
and
won't
work.
C
I
definitely
will
comment
on
your
talk,
and
maybe
I
will
also
reach
out
to
you
and
if,
if
possible,
we
can
come
up
with
some
like
first
year
draft
text
for
the
old
tap
before
before
next
week,
and
just
like
basically
put
this
minimum
requirements
that
we
came
up
with
into
the
old
tap
and
then
can
have,
we
can
have
like
a
discussion
based
on
that
or
maybe
even
people
can
even
comment
offline.
C
Awesome
thanks,
I'm
here
that
that
that
helps
us
a
lot
great
work.
C
Okay,
so
for
the
next
and
last
point
on
the
agenda,
I
just
wanted
to
talk
a
bit
about
context
propagation,
and
there
are
some
kind
of
some
ideas
that
came
to
me.
So
so
that's
basically
what
we
have.
Currently
we
talked
about
that
that
we
have
those
two
layers
of
context,
propagation
creation,
context
and
transport
context
and
both
basically
have
to
be
have
to
be
piped
through
the
intermediary.
C
The
transport
context
can
be
used
and
changed
by
the
intermediary
and
the
creation
context
has
just
to
be
like
transported
like
without
without
being
changed.
So
we
rely
on
the
fact
or
we
require
that
this
creation
context
arrives
at
the
consumer
as
it
was
sent
by
the
producer
and
for
the
transport
context.
We
are,
we
basically
be
allowed
intermediary
to
use
and
change
this
context,
and
I
was
looking
a
bit
into
this
week
into
how
this
context
propagation
can
happen
for
different
protocols.
I
mean,
I
think
we
have
mqb
mqtt.
C
Those
are
popular
protocols
where
this
context
has
to
be
propagated
via
those
protocols
also
http,
and
the
the
thing
here
is
that
I
kind
of
came
to
conclusion
that
we
need
to
to
specify
more
or
less
how
exactly
those
context
is
attached
for
each
protocol
and
how
it
can
be
extracted
and
read
for
each
protocol.
C
There
are,
there
are
a
w3c
kind
of
drafts
for
how
to
propagate
w3c
trace
context
via
mqb
and
mqtt.
The
thing
is
that
those
drafts
only
partially
partially
meet
our
requirements
because
they
don't
really.
They
don't
really
take
into
account
that
we
have
these
two
layers,
so
they
basically
presume
there's
one
layer
and
on
the
producer
side.
Basically,
we
have
this
one
context
that
we
attach,
and
we
actually
would
like
to
attach
two
different
contexts
on
the
on
the
producer
side.
C
So
yeah
I'm
currently
not
really
sure
how
to
best
proceed
there.
I
think
the
options
that
we
have
are
more
or
less
referring
to
those
to
those
wcc
drafts
and
and
trying
to
get
our
painters
that
we
need
into
those
drafts
and
the
other
option
that
we
have
would
just
be
yeah,
specifying
it
here
just
for
hotel
specific
how
this
context
should
be
attached
and
I'm
currently
not
sure
what
is
the.
What
is
the?
What
is
the
best
way
to
go?
C
I
think,
from
from
a
efficiency
point
of
view,
it
seems,
of
course,
best
to
just
use
what
is
there
and
try
to
fix
it,
but
I
also
from
talking
to
wcc
folks.
C
I
talked
to
them
like
some
time
ago
about
those
mqb
and
mqtt
drafts,
and
they
were
actually
not
too
happy
about
even
the
existence
of
those
drafts
so
sergey.
Who
is
in
the
in
the
committee?
There
said
that
he
actually
he's
he's
not
of
the
opinion.
That
is
that
this
should
be
part
of
the
w3c
specification,
and
we
also
I
mean
we
have
also
have
a
big
overlap
here.
Actually,
with
the
cloud
events
cloud
events
cardivan
spec,
they
have
this
distributed
tracing
extension
and
kelvins.
C
So
for
cloud
events
that,
basically
that
covers
what
is
encountered,
events
and
what
I'm
yeah
not
sure
is
yeah.
Also
the
relation
of
what
we're
working
on
here
to
the
w3c
specs
and
also
the
cloud
events,
because
more
or
less
we
are
replicating
or
replacing
what
cloud
events
has,
and
one
thing
that
makes
me
a
ponder
about.
That
is
that
I
saw
that
both
wcc
and
also
cloud
events.
D
D
The
the
the
creation
context,
layer
and
the
transport
context
layer
makes
sense
logically,
but
maybe
sort
of
physically.
It
doesn't
make
make
sense.
C
But
basically
you
mean
when
it
comes
then
to
actual
like
to
to
implementing.
D
D
A
Thank
you.
It's
not
that
this
community's
regret
is
that
they,
when
the
specifications
were
created,
we
didn't
have
this
concept
of
two
layers,
and
I
think
we
have
this
two
layers,
not
because
we
want
to,
but
because
we
we
have
to
so
like
we
are
trying
to
create
this
clarity
for
these
communities
as
well.
Apparently,
this
is
my
understanding.
F
Now
it
was
a
confusion
actually
in
the
cloud
events.
For
example,
I
mean
I
read
all
the
issues
there
and
it
was
what
I
was
working,
but
it
was
a
confusion
because
they
had
this
extension,
which
is
like
a
feud
in
the
event,
but
they
also
had
their
own
like
header,
so
it
was
kind
of
conflicting
like
people,
people
were
confused
because
they
they
didn't
know.
Okay,
should
I
use
the
thing
that
is
in
the
header.
F
Should
I
use
the
thing
that
is
in
the
event,
so
that
so
that
was
the
whole.
I
think
in
at
least
in
the
in
the
cloud
events
thing,
and
then
it
was
also
because
there
was
open,
open,
open,
tracing
and
and
and
then
open
11.
So
when
that
extension
was
created,
I
think
opportunity
was
not
yet
what
it
is
today
so
yeah.
So
I
think
that
contributed
for
for
the
whole
for
the
whole
confusion
there,
but
with
the
pr
that
is
open.
F
Now
I
opened
there
in
the
college
to
modify
it
now.
The
the
the
cloud
event
specification
about
this
extension
that
should
point
to
hotel
now
and
how
it's
used
and
from
what
I
saw
in
the
comments
from
the
cold
events
contributors
there.
They
had
a
meeting,
apparently
the
their
their
their
internal
or
their
their
spec
meetings,
and
I
think
they
kind
of
I
mean
they
said
there.
One
of
the
contributors
said
that
they
they
like
the
approach
or
the
the
direction
that
this
this
is
going
yeah.
F
C
Yeah
and
to
heart
back
to
chess's
question,
I
think
the
the
problems
for
both
w3c
and
cloud
events
is
that
they,
they
basically
partly
kind
of
make
concessions
to
this
two-layer
approach.
But
nobody
really,
I
think,
has
it
thought
through
to
the
very
end
and
kind
of
laid
it
out
in
in
the
spec,
and
I
I'm
not
sure
I
will
try
to
talk
to
wcc
people
again,
I'm
not
sure
they're
unhappy
about
the
two
layer
approach.
When
I
said
yeah
they
I
think
they
just
they
just.
C
I
think
when
I
last
talked
to
them
at
the
impression
that
they
think
that
this
whole,
basically
mqb
and
qtd
kind
of
details
related
to
message
propagation
are
out
of
the
scope
out
of
the
code
for
their
basically
work
groups
and
the
impression
that
I
had
like
the
strong
impression
I
had
with
wcc
and
also
party
with
cloud
events
that
if
you
would
tell
to
those
two
communities,
if
you
would
say
okay,
we
take
all
this
stuff
and
we
clarified
in
open
telemetry.
It's
one
central,
central
location
and
you're
rid
of
it.
C
They
would
all
be.
They
will
both
be
very
happy
about
that.
That's
true
that
that's
right!
Yes,
that's
what
I
meant.
I
think
it's
not
about
this
two-layer
approach.
It's
just
a
thing
that
they
for
them.
It's
kind
of
that.
They
feel
that
this
is
out
of
scope
for
their
project
and
they
would
be
happy.
I
think,
if
open
the
damage
you
would
take
the
dom
and
and
and
and
have
this
bit
specified,
on
the
other
hand,
yeah
it's
kind
of
fit.
C
As
I
said,
it
would
be
very
happy,
but
it
again
I
think
it
would.
It
would
blow
up
our
our
scope
here
a
bit
and
I'm
not
yet
sure
if,
if
that's
the,
if,
if
that's
the
best
route
to
go,
so
I
just
wanted
to
throw
it
out
there.
Maybe
people
can
have
the
thoughts
about
it
and
yeah.
I
will
also
talk
to
wvc
people
and
we
can
circle
back
to
that.
F
So
I
think
it
probably
would
be
more
fast
or
faster
if
we
define
ourselves
here
this
this
this
propagation
and
then,
if,
if
it
we
see
that
it's
good
or
makes
sense,
then
we
can
try
to
push
it
to
the
standard
to
w3c,
but
I
think
maybe
trying
to
get
there
the
standard
defined
in
w2c,
and
then
we
use
this
then
I
think
we'll
take
like
it
will
take
a
lot
a
lot
longer.
Yeah.
C
Oh,
I
see
what
you
mean
that
we
basically
come
up
come
up
with
some
like
mqb
mqtt,
specs,
here
yeah
and
then
basically
later
on
kind
of
once
it's
proven
stable
wcc
will
take
it
over
yeah.
A
F
Right
exactly
yeah
yeah,
the
baggage.
I
think
it's
going
the
same
exactly
because,
if
I
think
I
mean
I
don't
know
much
about
it,
but
I
think
if
we
try
to
either
reuse
what's
there
or
try
to
push
for
someone
to
work
on
there
on
on
the
standard
there
and
then
we
will
use,
I
think
we'll
we'll
lose.
I
don't
know
maybe
another
year
or
so,
because
I
don't
know
how
fast
things
go
there
right.
C
Yeah
so,
okay,
I
will,
I
will
circle
back
to
the
w3c
forks
and
and
make
that
suggestion
and
see
what
what
their
opinion
is
on
the
matter.
F
C
A
I
think
the
transport
context
is
like
the
definition.
How
it
flows
is
is
beyond
this
specification
right.
It
affects
potential
integration
with
intermediary
telemetry
and
also
that
this
is
not
something
we
control
it,
maybe
http
or
jpg
or
maybe
mkp
right.
It's
it's
already
defined
when
I
think
about
it,
and
this
specification
seems
to
depend
on
the
creation
context
only
and
if
we
don't
provide
anything
for
transport,
we
won't
lose
anything
right
now.
It
feels
like,
and
I'm
thinking
that
maybe
we
can.
C
A
C
Yes,
that
is
interesting.
The
mpqp
specification
actually
specifies
that
on
on
producer
side,
you
might
receive
two
different
contexts
in
the
in
the
mqb
message,
so
they
that's
why
I
said
they
somehow.
I
think
there
is
a
slight
idea
there
about
this
two
layer
model,
but
it's
not
really
worked
out
so.
A
C
But
yeah
I
will
bring
that
to
the
w3c
forks
and
we'll
see
about
feedback.
E
But
amtp
does
specify
both
the
application
properties,
but
also
what
is
it?
What
do
they
call
it
message
and
there's
message:
annotations
mesh
properties.
I
think
when
you
modify
it,
it's
in
two
places
and
I
think
that's
referring
to
you
the
mqtt
one
doesn't
so
it's
not
consistent
across
different
protocols.
C
Yes,
basically,
that
that
that
is
the
part
and
that
I
was
wondering
here
for
context
propagation
like
we
have
it
nicely
specked
out
here,
but
then
the
questions
that
users
will
have
yeah.
How?
How
do
I
do
this
for
mqb?
And
how
do
I
do
this
for
mqtt
and
how
do
we
do?
It
is
for
another
protocol
and
I
think
we
need
to
kind
of.
We
need
to
give
like
a
specification
here
for
or
some
kind
of
links
to
other
specs
for
protocols
dedicated
protocols
of
how
to
do
it,
and
that
is
yeah.
C
That
is
for
me
at
the
open
question
of
how
to
best
and
most
effectively
do
it
but
yeah.
I
will
check
with
wcc
folks
see
what
their
opinion
is
and
then
yeah
circle
back
next
week
and
they
can
maybe
decide
or
or
further
discuss
how
to
best
proceed
here.
C
Okay,
we
have
four
minutes
over,
so
travel
forks
did
not
chime
in
so
it
seems
we
have
our
own
meeting,
that's
great,
but
I
I
still
have
to
have
to
go
now.
C
So
thanks
all
that
was
a
great
session
thanks
army.
Thank
you
and
see
you
next
week.