►
From YouTube: 2022-06-09 meeting
Description
Instrumentation: Messaging
A
Everybody
good
morning,
good
evening,
let's
maybe
start
in
one
to
two
minutes.
A
Agenda
so
I
mean
somebody
put
something
on
the
trainer
for
next
week:
I'm
not
sure
what
it
was,
but
it's
an
address
x-ray
demo
yeah,
I'm
not
sure
who
put
it
up
there,
but
they
are
looking
forward
to
whoever
is
going
to
show
that.
A
Link
here
and
on
the
trend
for
this
week,
I
would
like
to
continue
where
we
left
off
discussing
last
week.
First
just
to
quickly
go
over
two
pr's
that
are
related
to
the
messagings
and
the
conventions
that
are
open
now.
The
first
one
is
this
pr
of
replication
protocol
attributes,
that's
a
pr
that
I
put
up
this
week,
but
middle
already
looked
at
it
and
what
that
pr
basically
proposes.
A
It
proposes
two
new
two
new
generic
or
more
or
less
generic
attributes
to
capture
the
application,
protocol,
name
and
application
protocol
version,
and
this
effectively
the
plan
is
to
use
this
to
replace
the
messaging.protocol
messaging.
The
protocol
underscore
version
attributes
that
we
have
here
in
the
messaging
semantic
conventions.
So
the
plan
is
to
get
these
two
attributes
out
of
the
messaging
semantic
conventions
and
have
them
replaced
by
these
generic
net
attributes.
A
So
we
get
the
we
get
our
messagings
back,
a
bit
slimmer
and
kind
of
more
more
in
line
with
other
semantic
conventions
that
probably
also
use
those
attributes.
A
So
if
we
have
some
time,
maybe
I
have
a
look
at
the
pr
and
if
it
looks
good,
do
you
approve
it?
Even
if
you
are
not
an
official
approver,
we
just
see
a
gray
check
mark
here,
but
that's
also
that's
also
valuable.
So
we
see
that
people
kind
of
want
this
change
and
are
aligned
with
it,
and
I
will
bring
probably
bring
it
up
next
week
in
the
spec
meeting,
so
we
can
close
on
this
one.
A
So
that's
the
first
pr
here,
that's
open
and
the
second
one
that
is
the
old
tap
for
context,
propagation
requirements,
and
there
is
ludmilla
and
trau
already
looked
at
this.
So
thanks
for
your
reviews
here-
and
there
is
two
open
questions,
and
maybe
we
can
go
over
those
go
over
these
open
questions
today.
One
is
from
zhao,
and
maybe
we
start
off
with
that
here
in
this
in
this
pr.
A
The
chord
of
one
layer,
the
creation
context,
layer
and
the
other
layer,
we
call
the
transport
context
layer
and
throughout
was
suggesting
that
maybe
we
we
settle
on
these
names
because,
with
this
creation
context
layer,
there
was
some
discussion
whether
it
caught
its
chord
creation,
context
layer,
it's
called
application
context
layer
and
we
I
I
think
we
settled
on
creation
context
later
then,
but
I
think
we
should
make
sure
we're
all
in
line
here.
Definitely
before
we
merge
this.
A
C
Maybe
maybe
this
is
inaccurate,
but
the
context
can
be
amended
and
and
changed
as
it
moves
like.
So
in
my
idea,
there's
multiple
different
layers
of
context,
there's
transport
context,
which
I
think
we
have
a
pretty
good
understanding
of,
but
there's
also
this.
You
know
the
application
created
or
the
creation
like
the
created
context,
but
I
feel
like
can't
the
creative
context
also
be
amended
by
a
consumer
down
the
road
like
added
to
or
is
it
not
true,.
A
I
I
think
the
point
of
of
this
document
here
that
that
of
this
old
tip
is
that
we
say:
okay,
there
is
this
creation
context
layer.
This
cannot
be
changed,
so
that's
basically
a
requirement
that
we
put
out
there.
That
is
okay,
the
creation
context,
the
producer
attaches
it
to
the
message,
and
this
should
be
basically
read
only
it
should
not
be.
Ideally,
it
should
not
even
be
possible
to
change
this
context
and
the
point
that
raw
makes
here
is
it's
mostly
about
naming
of
this
context.
A
We
currently
document
proposes
the
name
creation
context,
but
the
I
think
crowsing's
application
context
would
be
a
more
better
name
for
it.
So
I
just
wanted
to
put
it
out
there
and
see
if
people
have
like
a
strong
opinions
on
that.
D
The
only
thing
that
I
I
I
think
is
that
I
don't
know
if
it's
clear
for
everybody
else,
that
what
the
creation
layer
is
yeah,
because
I
mean
like
if,
if,
if
you
talk
about
this
like
like
what
does
this
creation
creation
layer
like?
D
D
Like
the
whole
it
it's
like
it,
it
comprises
of
of
everything
right
the
the
moment
it
was
created
and
then
everything
that
you
touch
it
so
the
because
we,
I
think
we
talked
about
at
some
point,
that
the
reason
that
we,
the
nice
thing
or
nice
side
effect
that
we
get
with
our
separating
the
transport
instrumentation
to
the
one
that
we're
doing
now
is
that
people
will
be
able
to
see,
for
example,
all
the
services
that
that
that
this
event
touched
in
the
application
so
like
they
have
this
nice
graph
or
chart
where
they
can
see.
D
But
then,
if
we
use
transport
layer
for
that
one
and
call
this
one
creature,
creation,
layer
or
creation,
it's
I
think
it's
not
matching
both
things,
because
if
the
one
is
transport,
then
what
what?
What
is
left
right
is
it's
my
application.
It's
things
that
is
happening
in
my
system
or
system
context.
I
don't
know
system
layer.
So
that's
what
I
was
thinking
when
I
was
reviewing.
D
A
Yeah
I
I've
two
remarks
to
that
throughout
the
first.
One
is
that
here
we
talk
about
in
these
future
possibilities.
We
talk
about
this
transport
context,
propagation
and
there
we
introduce
this
creation
context,
layer
and
transport
context
layer.
I
mean
before
that.
Actually
here
we
introduced
the
term
creation
context.
A
D
I
I
think,
the
the
part
on
top
the
creation
context.
I
think
that
part
is
clear
because
talking
about
in
the
initial
and
how
do
you
embed
into
the
message,
I
think
that
one
is
fine.
I
don't
think
because
that
one
is
it's
it's
clear,
the
case
more
on
the
below
one.
What
is
the
layer
that
we're
we're
trying
to
that?
This
whole
tab
is
trying
to
instrument
now
right.
It
is
not
the
creation
layer
right.
D
A
Yes,
yes,
we
are
currently
working
on
on
basically
this
this
this
higher
level
layer
and
that
that
is
basically
a
future
work
item
to
transport
content.
A
I
mean
the
the
second
point
that
I
wanted
to
bring
up
here
with
with
this
naming
of
the
layers
and-
and
that
makes
it
even
more
confusing-
is
that
I
mean
the
transport
context.
A
If
we
talk
think
about
this
transport
context
in
the
future,
that
will
probably
then
be
propagated
via,
let's
say,
mqp
mechanism
like
mqb,
basically
from
the
point
of
view
of
messaging
systems,
is
kind
of
a
transport
protocol.
But
technically
those
messaging
protocols
like
aimqb
and
mqttd
in
this,
like
osi
model,
are
application
layer
protocols.
A
So
I
think
it
gets
even
more
confusing
here
also
regarding
this
other
pr
that
I
showed
this
for
this
semantic
convention
attributes
for
capturing
application
layer
protocols,
because
here
we
will
put
like
we
will-
we
can
capture
mqb
and
mqtt,
because
those
are
like,
technically
speaking,
application
layer
protocols.
A
D
A
C
E
A
And
then,
and
then
the
question
is
whether,
when
we
name
this
here
application
layer,
whether
this
would
be
confusing
then
to
some
people
use
this
with
the
mqb
and
mqtt.
D
Yeah
now,
then,
I
agree
that
if
we,
if
there
is
already,
I
didn't
know
that
there
was
this
okay,
this
is
already
a
term
using
in
other
aspects.
So
that
probably
is
not
like
not
a
good
thing
to
mix
them
right
together,
but
I
still
think
that
we
should
probably
find
a
better
name
to
describe
the
layer
that
we're
trying
to
the
the
first
v1
that
we're
just
linking
consumers
and
producers.
A
I
mean
to
be
fair
this
here,
it's
also
just
under
future
possibilities.
So
I
think
every
terms
we
come
up
here
are
subject
to
change
still,
and
I
mean
this
sure
will
also.
This
will
make
it
into
the
into
the
spec.
That
is
just
the
future
consideration
in
the
old
tap.
Yes,
and
the
only
thing
that
make
it
will
make
it
into
the
spec
once
this
otp
is
merged.
Is
this
part
here
so
also?
So
I
think
we
definitely
have
the
this.
Is
this
name
here?
That's
not
cut
in
stone,
so
that's
definitely.
D
But
I
guess
we
still
need
to
have
some
some
consistent
name
for
whatever
we
want
to
call
this.
What
we're
the
v1
right,
because
this
is
going
to
be
introduced
at
some
point
and
we'll
talk
about
it,
because,
for
example,
what
I'm?
What
I
I
mean
is
that
some
someone
else
asked
in
the
cloud
events
back
this
week
about
these
two
two
headers
like
the
w3c
and
the
one
that
cloud
events
has
like
this:
their
way
to
transmit
the
creation
context,
and
somebody
just
asked.
I
think
it
was
the
day
before
yesterday.
D
They
just
said
why
there's
two-
and
why
is
this?
Why
this
is
there?
And
then
I
I
explain
and
then
I
need
that
word
to
say
now.
This
other
one
is
to
to
create
a
trace
that
is
bound
to
the
application
to
the
consumer
and
produce.
I
didn't
have
a
word
to
to
to
use
and
the
other
one.
I
said,
the
the
protocol,
the
protocol
instrumentation,
and
for
this
other
one
I
didn't.
D
I
didn't
have
a
word
and
I
feel
that
we
need
to
have
a
board
to,
because
we'll
have
to
present
this
to
the
tc
at
some
point
and
and
need
to
have
buy-in
from
the
technical
committee
and
so
on.
And
then,
if,
if
we
have
conflicting
wars,
then
I
think
it's
going
to
be
even
more
difficult
to
because
they
will
ask
like
like
what
are
you
instrumental?
What
is
this
and
yeah.
A
A
That
makes
sense,
but
the
creation
context
layer,
it's
not
necessarily
just
related
to
creation.
No
exactly.
It
is
the
creation
context
that
we
propagate
in
this
layer,
but
the
layer
itself.
It's
not
strictly
related
to
creation,
yeah.
A
Yeah
business
layer
would
be
another
other,
maybe
equally
bad
name
for
it.
I
I
I
don't
have
a
better
name
at
the
moment.
To
be
honest,.
A
In
the
document
we
could
what
they
definitely
could
do
like.
Let's
emphasize
this
name,
because
here
it's
like
in
italics-
and
it
should
suggest
that
that
is
some
kind
of
your
technical
term
we're
using
yes,
I
I
that
that's
definitely
something
I
could
try
that
we
basically
leave
those
two
layers
more
or
less
unnamed.
E
D
A
Message
context
would
also
make
sense
to
me,
because
I
mean
that's
another-
actually
good
way
to
see
that
in
on
this
level
here
on
this
first
lever,
the
context
propagation
works,
basically
message
based
sort
and
on
the
second
level,
that's
not
the
case.
The
the
context
is
not
bound
to
the
message,
but
it's
more
bound
to
like
individual
requests
or
like.
D
D
D
F
Great,
no
should
the
part
above
it
that
is
part
of
the
specification,
call
the
context.
The
message
message,
context
or
message
creation
context,
then
maybe.
A
Or
that
is
a
good
question,
because
it
definitely
is
helpful
to
be
able
to
kind
of
say,
okay,
this
context,
it's
kind
of
corresponding
to
this
layer.
A
Okay,
so
I
will
that's
good
good
suggestions.
Actually
I
will
I
I
will
fix
that
in
a
document,
and
hopefully
this
point
is
clarified
and
then
we
have
an
other
one.
That
also
was
brought
up
by,
and
luke
miller
had
some
opinions
on
that
too,
and
this
one
is
basically
about
the
last
section
in
the
document
also
the
the
second
future
possibility
for
the
standards
for
context
propagation,
and
I
think
here
it
was
not
clear
how
to
be
v
now
in
you
know,
in
in
using
v4
like
open,
telemetry,
open
telemetry
group.
A
How
do
we
relate
to
this
these
kind
of
standards,
because
these
standards
are
part
of
open
telemetry?
They
are
kind
of
external
to
us
and
how
does
the
work
that
we're
doing
here
relate
and
influence
those
standards,
and
I
had
some
pretty
convoluted
working.
There
were
wording.
There
show
also
suggested
like
a
simpler
wording,
and
I
made
a
change
here
and
basically
to
my
my
main
point
of
view
here.
A
What
I
wanted
to
want
to
say
here
is
that
they
are,
we
don't
own
those
ones,
those
are
kind
of
extraordinary
open
dynamite,
but
they
will
basically
adapt
more
or
less
based
on
the
requirements
that
we
make
here
also
in
this
document,
so
they
will,
they
will
kind
of
these.
These
external
standards
will
adapt
to
these
requirements
for
context
propagation
that
we
are
setting
forth
here,
and
I
think
that
is
the.
A
That
is
the
main
point
that
I
want
to
make
here,
and
I
mean
once
once
they
adapted
to
those
requirements
and
once
those
standards
are
stable
itself,
then
then
I
think
we
can
recommend
using
those
standards
in
the
open,
telemetry
document,
but
it's
kind
of
a
bit.
The
other
cat
bites
its
tail
there,
because
currently
those
are
unstable
or
like
in
a
draft
state,
and
we
want
to
come
up
with
something
stable
here
and
when
we
come
up
with
some
stable
guidelines
for
conventions,
we
cannot
really
recommend
something.
A
So,
basically,
as
as
I
see
the
sequence
here
is
that
first
open
telemetry
semantic
conventions
with
this
requirements
for
context
propagation
will
become
stable.
A
Then
those
protocols
will
adapt
and
implement
those
requirements
and
if
they
already
implemented,
they
will
just
like
verify
that
if
they
satisfy
the
requirements,
then
those
protocol,
extensions
for
context
propagation
will
become
stable
and
then
we
can
kind
of
reference
them
in
in
the
open
telemetry
document
here,
and
I
I
think
it's
just
worthy
of
making
clear
that
we
all
share
this
view,
but
ludmilla
was
suggesting
that
we
might
suggests
even
like,
as
those
protocol
extensions
are
not
stable,
yet
that
we
should
suggest
some
best
practice
of
how
to
propagate
context.
A
I
personally
would
prefer
to
refrain
from
that
and
leave
this
more
or
less
open
or
unspecified
for
now,
which
admittedly
makes
it
harder
for
people
trying
to
implement
the
semantic
conventions,
but
I
think
makes
makes
the
situation
easier
for
us
who
are
working
on
that
also
in
terms
of
backwards
compatibility,
because
any
recommendation
become,
if
you
put
any
kind
of
recommended
way
to
do
it
in
there
now.
I
think
we
will
not
be
really
able
to
break
this
at
some
point
in
the
future
and
probably
need
to
support
this
more
or
less.
B
I
understand,
but
let
me
explain
what
I'm
worried
about,
and
yes,
I
I'm
fine
with
either
decision
to
make
sure
we
we
know,
and
so
what
happens
today
is
with
current
messaging
conventions.
People
use
double
strategy,
headers
or
whatever
is
configured
in
propagator
the
b3
to
put
stuff
in.
So
as
a
result,
in
majority
of
cases,
by
default,
you
would
see
trace
parent
trace
date
in
case
of
amqp
or
I'm
not
sure
about
mqtt,
if
anything,
surprisingly,
anyway,
so
you
would
see
the
string,
ws
receivers
context
in
messaging
scenarios.
B
B
Whether
we
specify
it
or
not.
Well
collide
was
the
binary
thing,
then
every
instrumentation
will
have
to
say:
okay,
besides
the
header
name,
let
me
actually
go
and
check
the
length
of
it
or
the
format
somehow
and
like
this
backward
compatibility
will
hunt
us
down
anyway,
but
there
will
also
be
a
collision
on
the
hedonism.
B
I
understand
that,
like
the
mtp
standard
is
a
moving
target
and
we
can
say:
okay
there
we
will
take
care
of
it.
The
binary
protocol
alone
is
a
very
problematic
thing
that
we'll
have
to
solve
this
collision
problem.
B
Maybe
the
the
version
will
be
different
or
I
don't
know,
but
basically
maybe
we
will
postpone
solving
this
problem
all
together,
but
now
I
want
us
to
understand
that
there
this
problem
will
exist.
Well,
sorry
will
exist,
and
I
want
to
hear
your
opinions
whether
we
want
to
prevent
this
now
or
we
say.
Okay,
it
will
happen
we'll
deal
with
it
later.
A
Well,
I
see
so
just
to
summarize
this.
I
think
one
problem
that
that
you
pointed
out
here
is
that
customers
will
then
propagate
context
by
mqb,
and
they
will
just
like
put
the
trace
parent
and
trace
date
header
in
there,
in
like
the
plain
text
format,
but
mqb
in
future
might
then
require,
in
this
w3c
draft
to
be
these
to
have
this
headers
propagated,
like
in
a
binary
form,
and
that
might
create
basically
that
melting
cost
that
customers
are
propagating
is
not,
according
to
the
mqp
standards.
B
A
What
what
I
wonder,
what
levels
we
have
here
to
kind
of
mitigate
this
problem,
I
mean
we
can
more
or
less
recommend
people
to
use
the
current
draft
versions
of
those
standards,
but
the
windows
still
can
change.
B
A
A
A
As
far
as
possible,
I
mean
I
I
I
think,
the
the
currently
the
only
way
if
you
want
to
be
really
stable
and
want
to
ship
something
stable.
I
think
you
need
to
come
up
with
your
own
thing
and
not
use
the
mqb
draft
or
the
mqtt
draft,
but
but
basically
do
your
own
way
of
context,
propagation
and
kind
of
codify
this.
For
yourself,
I
I
think
currently
the
only
way
to
really
be
100
labor,
but
I'm
also
not
sure
if
we
should
really
promote
or
recommend
that.
B
Then
we
have
a
problem
that
it
should
be.
If
we
follow
this
road,
it
should
be
common
because,
as
we
discussed
last
time,
you
can
use
gms,
you
can
send
data
to
a
blocker
over
here
between
not
knowing
what
this
broker
is
and
we
measure
the
case.
We
did
exactly
this
because
of
this
problem
and
it
harms
me
down
for
years
since
we've
damaged,
and
everyone
asks
me
what
the
hell.
Why
do
you
do
this?
B
A
A
Then
the
standards
hopefully
implement
those
requirements,
and
once
does
it
once
that
is
done,
then
they
can
be
verified
again
those
requirements
they
can
be
made
labor,
and
then
we
can
say
here:
okay,
just
propagate
when
you're,
using
an
aim
to
be
propagated
with
wptp,
it
could
be
a
document
there
and
of
course,
then
also
be
extended
so
that
they
can
interact
with
a
binary
context.
B
Yeah,
it
sounds
like
whenever
a
binary
protocol
is
introduced.
Problems
like
this
and
probably
more
of
them
should
be
solved
along
with
introduction
of
binary
protocol
not
even
specific
to
amtp,
and
if
this
binary
protocol
is
correct
for
mkp
and
mqtt,
then
so
be
it,
and
it
will
just
delay
the
mcp
and
mqtt.
D
Link
to
the
propagator
api
spec,
isn't
that
already,
let's
say
better
or
enough,
because
that
that
says
what
what
propagated
to
use
and
how
to
populate
things
and
if
the
binary
is
after
it's
added
after
it's
a
problem
for
everybody
right,
not
just
not
just
us
or
did
I
not
get
it
because
I
also
don't
know
what
we
could
do
now
with
this
I
mean
I
understand
what
what
to
do.
That
thing
said
that
there
is
really
no
recommendation.
B
Well,
I
think
we
we
can.
I
I'll
try
to
find
anything
on
a
binary
protocol
and
then
maybe
I
will
create
a
new
shoe
in
this
pack
and
we'll
discuss
it
there.
But
basically,
if
the
binary
collision
the
encoding
is
solved,
then
it's
okay.
Whatever
customers
do
they
used
to
use
transparent
fine
if
they
use
something
else,
also
fine,
they
will
have
to
support
conversion
and.
B
A
That
mostly
actually
helps
drive
work
forward
on
the
standards
here,
because
it
makes
requirements
clear,
but
it
doesn't
really
help
like
instrumentors,
who
are
instrumenting
their
code.
I
think
it
doesn't
really
help
them.
It
actually
just
makes
some
problems
that
they're
facing
more
apparent
when
they
have
to
then
pick
a
context,
propagation
mechanism
that
satisfies
these
requirements.
So
I
think
this.
The
this
here
is
just
like
a
stepping
stone
to
a
to
a
final,
stable
solution.
B
Yeah
yeah,
so
I
went
through
the
entry
piece
to
expect
and
it
punctured
it
was
eating
here.
So
regardless
the
trace
parent
name,
there
will
will
have
to
be
changes
in
that
specification
before
it
can
be
used
to
the
part
of
this
expectation.
B
A
Then
I
will,
I
will
write
a
comment
here
and
maybe
then,
once
you
have
the
issue,
I
will
link
to
this
issue
from
here
and
I
will
also
then
yeah
write
a
comment,
comment
here
and
basically
try
to
point
out
that
what
we
have
here
for
now,
that
is
just
like
a
stepping
stone
and
actually
the
standards
for
context
propagation.
That's
actually
a
future
work
item
that
we
will
then
tackle
independently.
G
G
About
this
pr,
so
I
didn't
have
the
time
to
review
it
before
the
meeting.
I
will
do
it
later,
but
one
thing
that
I
think
is
missing
is
to
describe
that
the
create
context
is
not
always
possible
to
be
propagated
because
there's
a
lot
of
messaging
systems
where
you
don't
have
the
possibility
to
edit.
G
So
I
think
it's
worth
mentioning,
for
example,
in
ready
set
pub
sub,
you
can't
attach
adults,
it's
just
like
you,
send
the
payload
and
the
key,
and
that's
it
you
can't
add
anything
else
and
also
in
a
socket
io.
We
feel
familiar.
It
has
like
messaging
semantic.
You
can
broadcast
a
message
to
consumers,
but
it's
above
the
web
socket
protocol
which
has
no
way
to
to
attach
metadata
to
a
message.
A
G
G
B
G
Pub
sub
commands
like
that
they're
already
out
there
and
the
application
is
losing
them.
So
I
guess
it's,
they
prefer
simplicity,
but
in
these
cases
we
cannot
correlate
producers
and
consumers.
A
Yeah,
I'm
I
mean
that
the
old
tip
here
stays,
I
think,
deliberately.
A
A
bit
I
I
think
this
out
that
deliberately
doesn't
give
like
that
directions.
Here
I
mean
the
only
thing
that
facts
require
here
is
that
we
say
our
producer
should
the
data
creation
context
to
each
message.
So,
firstly,
we
don't
have
a
must
here,
so
we
have.
We
have
a
should
that
basically
says.
A
G
Yeah
because
I
think
it's
relevant
for
a
lot
of
messaging
systems
that
cannot
do
it,
so
it
could
be
nice
to
have
it
written
just
so
it's
not
vague.
So
this
is
a
one
thing.
The
other
thing
is
the
creation
context.
It
can
be
the
creation
of.
G
A
G
Yeah
it's
by
spec.
We
allow
it
in
the
spec
I
think
like
in
the
current
spec
and
also
in
the
future
spec.
We
said
that
we
will
allow
this
behavior,
so
I'm
not
sure
if
it's
it
should
go
into
the
hotep,
because
it's
a
dote-up
is
good,
as
is,
but
I
think
it
would
be
nice
to
state
that
this
creation
context
can
be
related
to
a
single
message
or
batch
of
messages.
So
it's
not
confusing
to
anyone.
A
Yeah,
honestly,
I
would
actually
like
to
keep
this
out
of
this
old
tap
and
add
this
to
the
next
level
tip
where
we
then
talk
about
all
how
messages
can
be
kind
of
linked
and
and
how
spans
can
be
linked
and
parented,
because
I
actually
think
adding
it
here
might
confuse
some.
A
I
think
here
we
should.
We
should
focus
on
how
context
is
propagated,
but
we
should
not
start
to
say
what
context
is
propagated
here.
I
think
that
we
should
do
in
the
next
in
the
next
pr,
because
also
all
those
those
products
here
they
don't
care
like
what
context
it
propagated
there.
They
just
like
they're,
it's
just
of
interest.
A
What
is
the
mechanism
to
propagate
this
context
and
how
is
it
propagated
and
and-
and
I
think
the
point
you
make
is
definitely
valid,
but
I
would
like
to
pack
this
in
the
next
pr
where
we
also
talk
about
all
the
where
we
talk
about
all
the
order,
ways
to
link
the
messages
together.
I
don't
have
this
open
now,
but
I
think
there
it's
it's
it's
better
to
keep
it
like
these
chunks,
consistent
and
and
not.
I
think
it
would
actually
add
some
confusion
if
we
would
start
packing
this
in
here.
A
Foreign,
you
can
just
add
a
comment
here
and
then
I
will
I
will.
I
will
add
the
remark
about
the
the
context
this
part
of
the
of
the
message,
if
you
cannot
send
it
via
metadata,
I
think
we
can
add
a
remark
about
it
here.
A
Okay,
so
thanks,
I
think
we
covered
to
open
to
open
points
here.
I
will
add
like
problems
to
that,
and
maybe
I'm
here
will
you
add
a
comment.
I
will
fix
the
text
with
your
suggestions
and
then
I
will
also
bring
this
up.
Bring
this
up
pr
up.
Maybe
next
week
in
the
in
the
in
the
spec
meeting
and
get
some
other
people.
F
A
For
mqp
and
mqtt,
it's
it's
basically
w3c
who
is
owning
those,
and
actually
I
think
it's
it's.
You
can
open
here.
It's
a
it's
an
extension!
That's
in
a
draft
state.
F
Currently,
yeah,
I'm
just
wondering
how
like,
when
they
go
to
like,
create
the
stable
version
of
this.
How
what's
the
best
way
to
make
sure
they're
aware
that
messaging
wants
to
use
that,
like
our
messaging
spec
wants
to
use
this
and
that
we
would
like
it
to
have
the
requirements
that
we
laid
out
in
our
spec.
A
The
way
to
make
sure
of
this
is
actually
here
you
see
like
cameron.
This
is
kind
of
an
author
of
this
mqp
and
I
think
of
the
mqtt2,
so
he's
actually
also
his
point
of
view.
Is
that
be
here
in
open
telemetry?
We
should
bring
these
requirements
and
then,
when
we
put
our
requirements
here,
then
we
can
work
on
or
people
can
work
involved.
A
People
can
work
on
stabilizing
these
documents,
because
I
was,
I
was
also
attending
some
of
these
wcc
meetings
and
asked
about
this
product
course
and
what
they
basically
said
is
that
when
you
hop
when
you
want
to
have
to
make
it
stable,
what
is
necessary
for
making
it
stable
is
just
yeah
testing
and
verifying
that
what
is
specified
here
actually
works.
A
So
what
they
basically
said
is,
if
you
want
to
have
this
table,
then
come
up
with
some
like
scenarios
test
and
verify
these
extensions.
Let
them
present
this
to
us,
and
then
we
can
talk
about
driving
this
to
a
to
a
stable
state.
So
I
think,
currently,
those
are
those
those
documents
here
in
kind
of
a
dormant
state,
and
I
think
it's
actually
more
of
us
than
to
kind
of
kick
kick
this
off
for
poke
people
to
drive
this
to
a
stable
state.
A
All
right
thanks-
and
it
might
also
maybe
involve
some
work
from
people
from
this
group
here
to
kind
of
maybe
to
verify
that
what's
in
here
corresponds
to
to
what
we
worked
out
here
in
in
our
documents.
D
I
think
they
have
some
tests
suits
right
to
to
to
make
sure
that
it
works.
The
way
is
specified.
A
Yes,
there's
a
test
suit
for
sure
for
the
http
stuff,
I'm
not
sure
about
this
amqp
stuff,
yeah.
A
But
but
the
other
wcc
people
who
own
these
standards,
they
are
rare
just
to
shortly
answer
your
questions
to
end
the
wrap
up.
They
are
aware
of
that.
We
are
working
on
this
and
also
clemency
is
basically
involved
in
both
groups,
and
he
is
also
there
obviously
of
our
work
here.
A
A
I
didn't
have
time
to
to
update
this
document
last
week,
so
it
still
has
broker,
but
I
think
here
I
think
this
discussion
in
my
impression
we
mostly
wrapped
up.
We
said:
okay,
it's
gonna,
stay
messaging,
the
system
and
we
are
not
going
to
give
the
list
of
possible
systems
here
in
this
document,
but
possibly
reference
another
document.
A
So
I
I
will
update
this
here
and
maybe
we
can
have
some
or
start
discussions
about
like
next
comments
that
ludmilla
made-
and
I
I
think
it's
I
think,
generally
the
comments
look
miller
made
a
drive
towards
like
a
simplification
of
this
first
proposal
that
we
came
up
with
here,
because
we
we
compared
to
the
to
the
existing
messaging
semantic
conventions.
We
came
up.
We
came
up
with
quite
a
more
like
fine
grained,
with
quite
more
fine-grained
attributes
here.
A
We
that
we
kind
of
made
a
distinguished
distinction
between
destination
and
source
and
with
double
we
duplicated
attributes
on
that,
and
we
had
special
attributes
like
template
or
temporary
and
anonymous,
and
I
think
one
of
the
main
points
that
ludmilla
is
making
here
is
that
he
suggests
striving
for
more
simplicity
here,
maybe
having
like
an
attribute
set.
A
F
I
know
in
in
the
early
discussions
on
this.
We
talked
about
having
just
one
and
I
think,
there's
two
two
reasons
that
we
ended
up
with
two
and
one
of
them
was
we
had
a
hard
time
figuring
out
what
that
what
we
should
call
it,
but,
but
I
think,
even
if
we
came
on
the
name,
the
other
reason
was
that
if
you
only
have
one,
then
you
kind
of
lose
out
on
the
other.
F
So
if
you
have,
if
a
consumer
knows
where
it
came
from
as
in
the
source,
the
question
is:
do
they
not
care
about
the
where
the
or,
where
the
original
destination
of
the
message
was
when
the
producer
sent
it,
and
maybe
the
answer
is
no,
if
we
think
it's
okay
to
search
through
the
trace
and
find
you
know
the
originating
span
and
look
at
what
its
destination
was.
But
those
were,
those
were
two
of
the
things
that
I
remember
talking
about
earlier.
B
F
That
was
yeah.
That
was
what
we
had
talked
about.
Did
we
we
set
up
for
a
producer,
the
destination
be
required
and
for
a
consumer
resource
would
be
required,
but
that
the
destination
is
optional.
On
a
consumer
span.
B
F
Yeah
I'd,
like,
I
think,
any
non-point
to
point
right,
a
generic
kind
of
you
know.
If
you
have
a
pub
sub
where
your
subscription
supports
wild
cards,
then
you
could
definitely
end
up
a
fan
out
from
the
producer.
Then
the
destination
and
source
would
be
two
different
things
and
I
think
we
could
find
you
could
find
some
examples
for
that,
for
sure,
rabbit
would
be
one
any
any.
Any
mqtt
would
be
another
yeah
yeah.
B
It
makes
total
sense
and
I
wonder
I
can't
we
try
to
merge
two
different
scenarios.
Okay,
I
see
on
the
consumer
side,
there
are
two
things,
but
then,
if
I'm
I
don't
know
I'm
an
ops,
I
want
investigate
network
failures.
B
How
would
I
do
this
regardless,
whether
it's
a
producer
consumer?
So
I
don't
need
to
write
or
thing
and
okay,
the
network
failures
will
be
probably
specific
to
different.
That
should
do
it
not
specific
topic
yeah,
then,
okay,
then
it
makes
sense
and
let
me
digest
it,
maybe
probably
that
this
choice
is
the
perfect
one.
A
I
think
the
use
case
that
to
end
points
out
here,
just
to
summarize,
is
that
yeah,
the
the
producer
sends
to
let's
say
qa,
but
then
the
the
consumer
receives
the
same
message
from
a
qb,
because
the
intermediary
does
some
routing.
So
in
that
regard
like
the
destination
in
the
sword
would
be
different.
B
C
A
And
maybe
you
only
have
like
the
source
on
there
and
if
you,
if
you
would
want
to
know
the
original
destination,
you
could
navigate
to
the
producer
span
and
look
where
the
message
was
actually
sent
to.
I
mean
that's
like
a
level
of
interaction
and
if
you
have
both
destination
and
source
attributes.
The
nice
thing
here
is
that
you
have
it
all
on
a
single
on
the
single
consumer
span
and
you
have
all
the
information
content.
G
B
How
typical
it
would
be
for
people
to
use
messaging
as
the
boundary
between
two
different
tenants,
so
they
don't
have
access
to
either
one
telemetry
and
then,
if
you
don't
have
access
to
producer
telemetry
down,
this
becomes
absolutely
essential,
because
maybe
you
own
a
broker
and
you
still
want
to
check
the
configuration
problems
and
routing
issues.
A
A
Okay,
I
will.
I
will
summarize
that
here
because
we're
almost
at
the
end,
I'm
I'm
not
sure
if
it's
if
it's
beneficial
to
start
or
go
deep
into
the
discussion,
it's
only
two
minutes.
I
will
summarize
it
here
and
maybe
we
can,
or
until
next
week.
B
A
Okay,
we're
we're
on
time
thanks
everybody
for
the
session.
This
was
really
good
and
that
before,
if
you
have
time,
maybe
you
can
look
at
this
pr
and
and
also
at
the
other
one
for
congregation
and
yeah.
I
will
put
this
past
fourth
next
week
in
the
stack
meeting
and
let's
see
how
far
we
get
with
driving
that
until
next
week,
thanks
everybody
right.