►
From YouTube: 2022-06-02 meeting
Description
Instrumentation: Messaging
A
B
B
B
B
B
B
C
A
From
the
store
I
missed
the
booth
I
was
talking
about.
A
E
Yeah,
I
am
fine,
I'm
trying
to
make
some
progress
on
http
conventions,
and
I'm
I'm
just.
I
can't
do
both.
So
I
try
to
use
my
time
wisely,
but
I'm
I
know
you
make
such
a
great
progress
here.
E
A
It's
the
ouija
view.
I
don't
know
if
you're
familiar
with
this
one,
it's
like
it's
the
one.
That's
like
re-cornering,
madaga,.
F
F
F
So,
on
the
trend
of
the
day,
I
think
you
can
skip
the
project
board.
There
are
like,
I
think,
two
two
main
topics,
the
first
one.
I
last
time.
I
said
that
this
big,
this
big
pr
that
we
have
for
the
messaging
semantic
or
for
the
this
big
old
tap
that
we
have.
I
I
talked
about
plans
to
split
it
up
and
I
split
out.
The
first
part
worked
on
that
this
week
and
there's
a
pr
up
here
for
the
context
publication
requirements
we
talked
about.
F
Okay,
here
we
go
so
here
we
have
this
this
context,
propagation
section
here,
it's
pretty
short,
but
I
think
it's
pretty
crucial
to
everything
else
that
comes
afterwards
and
yeah.
I
just
split
this
out
into
a
separate
outtap,
and
it's
here
there's
also
a
link
in
the
in
the
in
the
in
the
tender
and
yeah
be
great.
If
you
could
have
a
look
at
that
review
it
and
approve
it.
F
If
it
looks
if
it
looks
good
to
you,
it's
it's
not
that
long.
F
It's
basically
just
about
explicating
those
two
requirements
that
the
context
should
be
attached
directly
to
message
and
that
this
could
be
changed
by
the
intermediaries
and
yeah.
That's
the
otep
summarizes
our
reasoning
around
that.
Basically,
it
summarizes
our
discussions
so
yeah,
please,
please
have
a
look
review
and
maybe
maybe
a
proof.
I
think
if
we
show
that
we
here
from
the
messaging
work
group
are
aligned.
That
goes
a
long
way
in
also
convincing
other
people
to
to
approve
this
outtap
and
then
yeah.
F
I
will
also
work
on
as
a
next
step
splitting
out
the
trace
structure
in
a
separate
o
tab
that
will
then
involve
or
or
or
or
what
we
have
here
in
our
examples,
we'll
have
x
explicate
all
that
that
will
very
likely
be
a
bigger
road
tap
and
also
more
controversial
that
that
will
be
the
second
one.
I
will
start
working
on
splitting
that
out
and
then
the
third
one
will
then
contain
the
attributes,
our
like
proposal
for
for
attributes
and
yeah
there.
F
We
are
not
done
with
discussion
yet
so
continuing
this
today.
F
Awesome
thanks
for
then,
let's
go
to
the
next
point.
We
had
some
ongoing
discussions
about
attributes
and
ludmila.
She.
She
commented
on
the
pr
and
she's
I
think
she's
also
here
today.
Yes,
so
maybe.
F
Awesome,
maybe
we
can
go
through
the
comments.
Look
miller
made
on
the.
F
Pr
yeah.
F
Yes,
let's
go
through
it
right
away.
I
think
that's,
I
think,
there's
nothing
else
on
the
channel
besides
this
genre
attribute,
so
we
can
maybe,
let's
start
with
it
right
now,.
E
Okay,
yes,
so
a
few
things
I
think
some
of
them
are
very
simple.
Others
are
probably
worth
the
discussion
ready
for
one,
a
small
suggestion.
We
use
database
system
rpg
system
somewhere
else,
or
maybe
we
should
keep
messaging
system.
Just
for
the
sake
of
consistency.
E
I
don't
know
it's
just
a
suggestion,
so
we
we
don't
have
to
go
into
very
discussion.
We
can
even
take.
H
F
Just
to
note
on
this,
I
think
that
is,
that
is
fine
for
me.
We
just
need
them,
because
remember
system
caused
some
confusion
before
what
is
the
system,
I
think
we
just
need
to
clearly
define
like
messaging
system.
What
does
it
mean
for
us
here
and
for
two
weeks
back
there
and
we
basically
like?
I
think
we
need
to
make
clear
that
for
system.
F
We
basically
expect
like
a
kind
of
an
identifier,
that's
related
to
the
broker
to
the
endpoint,
and
I
think
we
just
need
them
to
kind
of
make
it
clear
in
the
description,
but
I
don't
have
any
problem
with
sticking
with
messaging
system
also
seeing
that
it's
consistent
with
this
with
what
is
used
in
other
other
places,.
E
Oh,
the
system
is
just
say
what
it
is
like
kafka
or
rabbit
mp.
I
Yeah
the
re,
the
the
trouble
we
had
with
it
was
for
things
like
amqp,
like
if
you're
an
amkp
api
as
an
example,
you
know
you
the
system,
it
the
broker
implements.
There's
a
system,
that's
implementing.
That
is,
should
the
system
be
the
protocol
in
that
case,
and
then
another
case
is
like
jms,
you
know,
there's
a
jms
provider
underneath
what
like
is
it
up?
I
Can
we
only
fill
that
in
with
auto
instrumentation
by
the
provider,
or
should
it
say
jms,
I
think
jms
doesn't
really
say
it's
just
an
api,
so
I
guess
it's
understanding.
What
system
should
be
in
all
of
those
scenarios?
That's
and
I'm
fine
with
keeping
it
just
have
to
figure
out
what
what
makes
sense
in
these
different
scenarios,
where
you
don't
know
if
you're
kafka
or
sqs
or
whatever.
E
My
understanding
would
be
that
probably
each
of
the
things
we
define
here
would
have
some
custom
behavior
and
maybe
some
extension,
some
custom
attributes
specific
to
the
system,
and
then
this
thing
would
be
used
to
identify
what
what
what
extension
it
is,
or
maybe
some
specific
behavior.
So
as
far
as
I
understand
it
is
it's
the
the
broker
technology.
E
F
E
F
I
think
the
point
is
making
it's
a
good
one.
That
is
basically
that
this
messaging
that
system
kind
of
having
when
this
messaging.system
equals
kafka.
Then
we
know
okay,
we
should
we
can
look
for
those
attributes
here
or
when
it's
rapid
enqueued,
I
mean
okay,
we
can
look
for
those
attributes
or
when
it's
I
don't
know,
azure
event
hubs.
We
can
look
for
another
set
of
attributes.
F
I
think
it's
just
kind
of
to
to
also
denote
which
kind
of
special
set
of
also
sub
attributes
we
can
expect
and
and
can
look
for.
I
I
think
that
sounds
useful
now.
I
could
actually
also
imagine
that,
with
that
I
can
imagine,
jms
does
make
sense,
because
I
can
imagine
you
would
want
some
things
that
are
jms
concepts
and
you
might
have
a
messaging.jms,
but
then
you
might
also
have
a
provider
who
injects
their
own
things,
and
so,
in
a
way
you
might
have
multiple
quote
unquote:
systems
in
a
single
span.
F
I
Yeah,
although
and
and
if
we
don't
necessarily
insist
that
it
be
a
broker
like
I,
I,
there
are
amtp
concepts
where
you
might
want
messaging.amqp,
dot
attributes
and
if
you
say
the
system's
amtp
and
then
that's
a
hint
that
okay,
I'm
going
to
look
for
messaging.amtp
information.
That
sounds
okay
to
me.
J
There's
a
there's
always
the
tension
of
of
what
level
you
want
to
be
acting
on.
If
we
so
gms,
for
instance,
is
an
ap
is
purely
an
api
standard
right
and
you
can
send
using
a
using
jms,
but
you
may
want
you
may
pull
messages
out
using
using
some
other
api.
It's
basically
just
a
client
api
and
having.
J
Anchoring
on
the
protocol
level
gives
you
more
gets
you
closer
to
the
broker,
if
you
would
say
so,
for
instance,
if
you
use,
if
you
use
jms
using
the
apache
cupid
gms
provider,
you
can
speak
to
activeq,
you
can
speak
to
service
bus.
You
can
speak
to
cupid,
you
can
speak
to
a
bunch
of
brokers
and
you
can
do
that
because
they
all
have
amkp
under
the
covers
common.
J
So
there's
a
there's,
a
question
here
of
of
whether
you
want
to
have
protocol
bindings
or
make
protocol
level
statements
about
you
know
common
protocols,
mqtt
and
and
amkp,
etc,
or
whether
we
want
to
go
and
anchor
that
on
the
on
the
api
surface
areas
more
it's
or
both,
but
that's
the
that's.
The
the
the
risk
is
of
of
doing
this
on
the
apis
is
that
you
have
lots
of
variations
there
with
probably
unevenness
between.
F
J
F
F
F
So
it
is
related
to
brokered
that's
why
we
named
it.
We
named
it
a
broker,
but
trusted
millie's,
arguing,
arguing
that,
for
sake
of
consistency,
we
should
name
it
back
to
system,
but
it's
still,
I
think
the
question
that
ram
brings
up
is
what,
if
what,
if,
on
the
we
don't
know,
what
broker
we're
actually
using
what
should
go
in
there
and
that
is
kind
of
problematic,
because
this
messaging
dot
system,
it
is
a
required
attribute.
F
F
D
Of
yeah
that
are
like,
like
orm
for
database,
they
do
it
for
messaging
systems,
it's
just
an
abstract
api.
You
can
send
a
message
and
it
gets
sent
to
the
relevant
broker
and
you
don't
always
know
it.
J
Correct
so
in
in
the
in
the
case
that
I
just
cited
this,
the
cupid
jms
provider
translate
jms
into
into
amkp
and
there
are
several
brokers
which
are
compatible
with
the
amqp
binding
to
jms.
J
E
J
E
Okay
make
sense,
and
then
the
client,
the
producer
does
not
even
know
which
broker
it
deals
with
in
this
case
right.
So
it
cannot
even
possibly
put
information.
G
E
Okay
and
then
it
means
that
only
generic
semantics
applicable
to
all
systems
from
this,
this
document
we're
trying
to
create
applies,
and
then
we
can
either
say:
okay,
it's
not
a
required
attribute
and
we
can
just
skip
it.
If
we
don't
know-
or
we
can
say
it's
other
generic
or
find
some
name
that
says
okay,
this
is
just
a
generic
thing.
The
reason
why
we
need
this
attribute
is
because
consumers
would
want
to
rely
on
something.
Okay,
I
have
messaging.system
or
messaging.broker.
G
E
F
G
Because
what
load
meter
said
it
is
used
by
other
components.
Couldn't
this
this
this
other
components
use
the
the
message.protocol
attribute
thing,
because
that
one,
where
you
always
have
right,
it
is
required
as
well.
F
No,
I
think
messaging.
The
protocol
is
not
required.
I
think
the
only
required
attributes
we
have
currently
are
messaging,
the
broker
messaging.operation
that
we
require
all
messaging
stands,
and
the
point
is
basically
that
the
other
some
kind
of
some
tracing
analytics
backhand
just
cease
messaging
dot
system
and
now,
okay,
this
is
a
messaging
span,
so
wait
yeah.
E
G
G
I
mean
it's
not
not
yet
there,
but
there
will
be
this
instrumentation
scope,
things,
instrumentation,
scope,
attributes
and
those-
and
these
things
could
be,
could
also
go
there,
but
with
the
name
of
the
jms
provider,
things
like
that
could
be
there
as
well
as.
F
D
G
No,
no,
I
just
meant
because
I
think
in
some
other
discussions
or
the
days
we
discussed
where
to
put
this
information
like
the
library
name
or
or
the
thing
that
is
generating
it
like
this
jms
providers
stuff
like
that,
and
I
think
we
just
we
discussed
a
bit
and
maybe
coming
up
with
new
attributes
here.
Not
for
that,
but
I
think
we
probably
shouldn't
do
that.
Like
like
honey
said,
maybe
we
can
reuse
the
other
tape,
but
not
for
for
back
ends
to
do
any
logic
on
it.
D
I
have
to
say
that
it's
very
convenient
to
have
this
messaging
dot
system
and
to
know
that
it's
always
there
and
I
think
we
shouldn't
be
really
strict
about
it
about
populating
it
with
the
correct
value
we
just
have
to
do
like
something
that
makes
the
most
sense
like.
If
we
know
the
system,
then
we
write
the
system.
If
not,
we
write
the
library
name,
that's
my
opinion,
because
it's
so
convenient
to
know
that
it's
always
there
like
inspector.
E
Is
it
fair
to
say
that
if
you
have
other
attribute
messenger
does
something
else
which
is
required
and
always
there,
then
it
will
be
as
convenient
as
messaging.
The
system.
D
Yeah,
so
it
it
only.
Let
me
knows
that
it
implements
the
messaging
specification,
but
imagine
you
want
to
take
these
attributes
and
construct
some
meaningful
text
out
of
them
like,
for
example,
for
a
header
in
the
ui,
or
I
don't
know
for
many
usages.
D
D
Yeah
so
then
it
it
means
that
you
have
to
be
aware
of
all
the
different
possible
attributes
that
you
can
get
and
the
code
becomes
like.
If
there's
no
system
then
try
this,
and
if
you
don't
find
this,
try
something
else,
and
it
really
makes
it
out
write
a
generic
code.
Yeah
and
they're
all
optional
yeah
makes
really
complicated
so
like
I'm,
I'm
in
favor
of
always
populating
a
messaging
dot
system
or
messaging.,
but
right
the
most
meaningful
thing
we
can
write.
It.
F
Yeah,
I
think
the
problem
here
is
that
it's
kind
of
quite
hard
to
specify
and
at
the
end
it
might
be
unclear
for
people
what
to
put
in
there,
because
I
mean
if
we
give
it
a
more
limited
meaning
and
with
the
okay
messaging
system,
that
basically,
that
is
the
name
of
your
broker
like
kafka,
evident
queue
or
event,
hubs
or
sqs.
F
That
is,
and
if
you
don't
know
the
name,
it's
other
or
unknown,
that
is
kind
of
a
very
kind
of
clear
definition
and
people,
I
think,
will
know
what
to
put
in
there.
Whereas
when
you,
when
we
say
just
put
in
what
makes
most
sense,
maybe
it's
the
broken
name.
Maybe
it's
the
library
name.
Maybe
it's
something
else.
I
think
it
will
actually
be
hard
for
people
to
know
what
to
put
in
there.
F
I
mean
what's
what,
when
they're,
using
when,
when
they
are
using
like
jms,
but
they
know
the
broker
they're
using
when
they
know
both
and
then
it
might
be
unkey
for
people
people
they
put
in
there.
D
G
D
E
I
like
the
idea
of
keeping
things
consistent
with
database
and
rpc,
where
we
have
it
and
there
they
say
that
there
is
a
list,
it's
an
annum
and
they
document
all
possible
values,
and
they
also
say
that
the
custom
values
are
allowed
and
also
they
say
that
the
fallback
is
other
sql.
The
rpc
is
different.
Actually
they
don't
have
a
fallback,
but
I
think
this
would
be
a
good
start,
and
if
we
do
something
like
this.
F
Possibility
that's
what
miller
proposed
that
they
just
yeah
provide
like
a
list
of
possible
of
possible
attributes.
Yeah.
G
F
F
And
then,
basically
we
just
then
this
idea
just
would
be
to
do
it
similar,
like
for
db
system
and
just
basically
provided
a
list
of
possible
values
that
are
supported.
I
mean
here
we
have
other
sql.
I
mean
that
could
just
then
for
for
free
could
just
happen
a
thing
like
other
underscore
mqp.
I
think
that
would
be
the
message
equivalent
of
address
ql,
you
just
know
you're
using
mqb,
but
you're.
Not
you
exactly
are
using
which
you're
not
exactly
knowing
which
broker
is
on
the
other
side,.
G
F
Okay,
then,
a
little
connected.
D
F
F
J
You
can
yeah,
I
think
you
can
have.
You
can
have
reference
standards
like
mqtt,
amkp
and
nats
and
whatever,
like
the
probably
open
source
projects,
but
I
always
find
product
names
brand
names
to
be
iffy
right.
We
all
now
think
that.
Sorry,
if
I,
if
I
step
on
anybody's
toes
here-
but
we
all
think
like
vmware-
is
something
that
will
be
there
forever,
but
you
know
who
knows
so.
J
I
find
that
very
I
find
that
problematic
as
and
I
think
doing
that
as
a
string,
whereas,
like
okay
put
in
the
name
of
your
product
name,
that's
fine,
but
having
a
list
in
the
in
the
in
the
normative
text
that
contains
products
and
brands
is
problematic.
J
Like
user
use,
your
use
your
brand
name
and
your
product
name
at
your
own
risk,
but
having
a
reference
that
you
can
go
and
rely
on.
I
find
that
always
problematic,
because
we
know
how
our
industry
works
right
and
the
product
may
be
there
forever,
but
may
have
have
a
new
name
for
all
kinds
of
reasons.
Next
year.
E
Clemens
can
can
we
try
like
the
scenario
where
it
would
be
important.
Imagine
we
want
to
visualize
event
absorb
amazon
sqs
and
we
want
to
put
an
icon
there
and
we
want
users
to
be
able
to
navigate
to
this
resource
in
their.
J
E
E
J
J
This
is
to
make
this
a
a
should
and
then
have
an
a
list,
that's
external
to
the
document,
which
is
how
several
other
standards
do
this,
where
you
have
effect
and
and
when
you
think
about
how
ietf
rfcs
do
this
in
when
they
have
things
like
this
there's,
usually
a
registry
with
names
which
is
separately
maintained,
often
by
iana,
which
kind
of
enumerates
the
current
values,
and
you
can
go
and
maintain
that
list,
and
then
it's
effectively
this
this
here
points
to
that
other
document
and
then
there's
a
should
where
you
know
and
that
doesn't
break
anything,
and
then
you
maintain
that
list
separately,
but
it's
that
also
puts
the
work
basically
puts
in
and
puts
an
exclamation
mark
here
that
says
yeah.
J
You
know
that
list
may
change,
so
you
should
be
ready
for
not
adapting
to
it,
but
it
doesn't.
It
doesn't
cause
a
breaking
change
in
the
core
stack
right
for
me.
For
me,
it's
really
in
all
these
things.
It's
super
important
for
the
core
spec.
Once
it's
stamped
one,
oh
to
best,
not
change.
E
And
it
would
also
be
great
because
this
document
cannot
accommodate
all
future
possible
conventions
and
extensions.
Correct.
J
But
an
external
external
document
can
so
if
you
look
at
ayanna
and
all
the
various
registries
that
they
maintain
that's
what
that's
what
they
are
for
right,
the
the
like,
for
instance,
port
numbers
for
reserve
part
numbers
for
tcp
and
udp
right.
They
are
maintained
in
an
external
registry
and
they're
protected
by
a
mechanism
that's
defined
in
those
in
those
protocol
specs,
but
they're,
not
specific
they're,
not
saying
http
has
port
80,
but
there's
an
external
list.
That
does
that
so
and
then
there's
there's
plenty
of
other
examples
for
this.
J
So
that's
what
how
how
I
would
do
this
not
put
it
into
the
document,
but
put
it
into
the
second
doc,
which
is
the
registry
for
it,
and
then
people
can
do
and
can
do
prs
on
it
and
then
also
a
further
thing
that
I
would
do
in
that
area
is
have
a
principle
by
which
products
can
be
included
here
in
that
list
and-
and
I
won't
make
any
suggestions
of
how
that
principle
is
formed,
but
there's
always
a
risk
that
some
startup,
which
is
just
starting
to
build
a
message
broker,
will
use.
J
F
That
makes
also
sense
to
me,
so
basically,
then
we
have
the
messaging.system
and
we
we
link
to
a
list
of
possible
values,
but
those
list
is
not
part
of
the
spec.
J
F
That
sounds
good
to
me,
and
I
think
in
in
to
add
to
that
anyway,
think
that
we
will
that
there
are
also
are
those
specific
messaging
system
like
fifa,
apache
kafka,
and
we
have
rocket
mq
and
others
here,
and
I
think
for
those
who
said
anyway
have
separate
documents
in
the
semantic
conventions,
and
I
think
also
those
separate,
for
example,
a
battery
rocket
mq.
Then
this
is
a
separate
document
that
they
can
say.
F
Okay
in
the
case
of
a
battery
rock
mq
messaging,
the
system
must
be
this
value
and
then
we
know
it's
rocket
and
queue.
So
we
also
then
have
this
basically
specified
in
the
system
messaging
system,
specific
document,
but
we
don't
have
it
in
the
kind
of
generic
document
there.
We
keep
the
messaging
the
system
like
we
don't
give
any
value.
We
just
link
to
this
other
list.
That
sounds
good
to
me.
G
I
also
add
this
a
summarizer
between
the
document
in
the
notes
as
well.
E
I
think
it's
other
and
I
think
if
we
will
ever
find
need
to
do
something
gms
specific.
Then
we
would
have
a
set
of
gms
attributes
and
we
will
put
jms
there
right.
Then
it
could
be
generic
mpp
or
so.
Basically,
this
is
the
string
that
would
only
make
sense
to
if
we
have
other
semantics
depending
on
it
and
if
not
it's
just
other.
E
F
F
F
Okay,
I
will
then
here
make
the
changes
as
well
suggested.
I
will
rename
it
back
to
system
to
be
consistent,
and
I
will
also
add
to
the
documentation
here
that
we
will
establish
like
a
document
in
a
separate
location
that
is
not
part
of
those
conventions
and
that
will
give
a
list
of
possible
or
recommended
values.
E
Yeah,
so
it
seems
that
we
currently
have
just
messaging
destination
or
source
names
and
the
main
concern.
I
have
it's
not
clear
what
it
exactly
means
there
were.
Many
systems
have
different
sorry,
many
systems
support
tenancy.
So
I've
done
some
investigation
and
I
found
that.
E
Some
things,
if
you
have
an
end
point,
you
don't
have
multiple
queues
topics
or
other
things
inside
the
bro
corporate,
so
it's
sqs
sns,
google,
pop
stop
and
azure
event
grid,
but
others
support
tenancy
and
it's
not
as
straightforward
as
one
thing,
I
think
pulsar
supports
canon,
namespace
and
topic.
So
this
is
like
a
tree
structure
and
in
this
sense
I
suggest
that
we
clarify
what
exactly
destination
means
and
we
need
to
have
multiple
attributes
to
describe
the
endpoint
and
also
describe
the
tenant
within
this
endpoint.
D
We
had
a
discussion
last
week
about
it,
because
what
we
want
to
store
in
the
destination
name
is
like
an
address
like
like
the
route
equivalent
to
http
route,
but
it
can
contain
a
multiple
elements.
So
we
thought
maybe
to
use
a
array
for
this
attribute
value.
E
I
think
that,
having
an
end
point
using
some
generic
span,
attributes
like
not
pure
name,
not
peer
ip
net
purport
would
would
be
very.
It
will
be
easy
for
backhand
that
doesn't
even
understand
messaging
semantics
to
show
something
if
they
want
to
write
and
if
we
can
put
all
the
fqdns
there,
then
the
messaging
semantics
will
only
describe
what
happens
in
messaging,
and
then
I
suggest
that
maybe
things
that
don't
support
tenancy
won't
have
anything
there.
E
D
So
I
think
the
end
point
is
in
the
url
and
also
we
allow
a
net
attributes
so
that
if,
if
these
unknowns
they
can
be
populated
and-
and
I
think
their
messaging
destination
is
only
in
the
messaging
context,
as
you
said
right,
so
it
shouldn't
contain
a
k1.
It
should
contain
the
q
name,
the
topic
name,
the
exchange
name,
routing
key.
All
these
things
that
identify
how
their
message
is
routed
and
what's
the
addresses.
F
I'll
just
do
just
to,
I
think,
to
summarize
what
the
what
is
done
in
the
current
current
message,
semantic
conventions,
which
I
think
is
pretty
unclear
and
vague.
What
they're
currently
is
done
is
that
here,
destination
is
defined
in
the
term
essence,
either
as
the
name
of
a
topic
or
a
queue.
F
So
that's
what
is
said
in
the
current
semantic
convention
says
destination.
It's
either
the
name
of
a
queue
or
topic,
and
then
there
is
this
messaging
url,
which
is
kind
of
an
unspecified
thing.
Mostly
it
can
be
any
url,
but
usually
then,
in
this
url
you
find
like
other
parts
to
uniquely
identify
your
destination.
For
example.
Here
we
see
that,
for
example,
the
queue
name
is
duplicated,
also
in
the
url.
But
here
you
also
have
then
the
kind
of
the
the
endpoint
name
and
some
other
identifier.
E
I
agree,
I
think
maybe
this
is
something
we
can
clarify
by
building
some
prototypes
right
and
it's
it's
hard
to
predict
how
how
far
this
this
approach
would
go.
F
Yes,
I
think
a
problem
we
have
here
is
that,
in
the
existing
semantic
conventions,
like
destination
is
kind
of
clearly
defined
in
the
dream
sense
as
either
the
name
of
a
queue
or
topic.
But
we
didn't.
We
didn't
kind
of
even
introduce
the
concept
of
keyword
topic
here,
because
it's
kind
of
I
think
we
don't.
We
don't
want
to
go
like
into
the
basically
hms
terminology
here
in
the
gms
concepts
people
know
they
want
to
stay
above
that,
and
but
we
refrained
from
introducing
the
q
and
copic
terms.
F
J
In
in
in
npt
in
mkp
there's
a
the
concept
is
the
node
which
is
abstract
and
that's
effectively
the
the
thing
you
interact
with
and
that
might
map
to
any
entity
may
map
to
a
topic
may
map
to
a
stream
that
may
map
to
a
queue,
and
the
protocol
is
not
specific
about
that
in
mqtt,
the
topic
name
is
just
a
string
and
what
the
broker
does
with
it
is
really
up
to
it
and
there's
only
there's
various
implementations
of
mqtt.
J
Some
of
them
have
an
explicit
notion
of
of
an
entity
and
a
thing
that
kind
of
handles
a
particular
subset
of
the
graph,
and
sometimes
it's
just
that
the
the
broker's
own.
You
know,
I
would
say
the
namespace
anything
sits
under
the
host
name
is
a
single
it's
a
single
entity,
so
that
all
depends
on
and
then
in
kafka.
J
The
name
is
the
topic,
but
all
of
those
things
have
you
know
particular
semantics
that
are
sometimes
specific
to
the
implementation
sometimes
specific
to
the
protocol.
But
it's
ultimately
just
the
name-
and
I
think
here
for
the
standard
that
should
be
as
neutral
as
possible
and
not
take
a
stance
on
what
the
topology
and
the
semantics
of
that
thing
are.
I
J
The
two
field
is
an
attractive
field
to
use,
but
in
practice
it's
something
that
the
applications
set
and
that
the
brokers
doesn't.
The
broker
typically
doesn't
consider.
I
Okay,
but
what
I
was
thinking,
what
we
sort
of
talked
about
a
little
bit
last
week
was
on
a
per
messaging
system
or
protocol
basis.
You
would
choose,
you
know
how
to
formulate
a
destination
name,
and
if
it's
made
up
of
multiple
parts
that
you
could,
you
know
then
have
a
messaging
dot.
I
Whatever
you
know,
system
dot
like
if
you're
a
rabbit-
and
let's
say
you
wanted
to
consider
the
exchange
and
the
routing
key
is
two
parts
of
your
destination.
I
You
could
have
messaging
dot,
you
know
rabbit
dot,
exchange
and
dot
routing
key,
and
that
way
you
can
kind
of
take
the
string
that
combined
to
these
information-
and
you
can
get
at
the
pieces
of
it,
and
that,
because
I
worry
about
trying
to
impose
too
much
structure
in
here
that
maybe
doesn't
map
to
any
one
technology
very
well
and
also
doesn't
map
to
future
messaging
systems.
I
Well,
if,
if
we
kind
of
keep
what's
in
the
core
part,
rather
generic
and
and
rely
on
sort
of
per
messaging
system,
extensions
to
to
better
express
that
system's
characteristics,
I
think
that
might
be
a
better
approach.
J
The
routing
the
routing
key
is
already
something
that's
iffy,
because
it
kind
of
is
a
it's
a
parameter
into
the
routing
engine
at
the
name
that
you
addressed.
J
J
You
can
set
four
different
freeform
properties
on
the
message
and
then
you
just
run
a
sql
query
on
the
on
the
back
side
of
it,
which
goes
and
and
evaluates
those
so
rabbit
in
like
where
the
routing
key
comes
from,
is
kind
of
a
simple,
simplified
version
of
that
sort
of
metadata.
That's
usable
for
routing,
but
it's
it's
the
same
thing
so
the
destination.
The
name
is
the
the
the
exchange
and
then
everything
else
is
just
extra
routing
metadata.
J
J
But
then
I
think
beyond
that,
it's
all
custom
like
a
a
a
routing
key
is
something
that's
very
specific
to
rabbit
and
a
partition
key
is
something
that's
very
specific
to
kafka,
because
it
also
has
has
an
effect
of
how
you
go
and
construct
the
client
etc.
E
And
to
the
question
of,
should
we
put
if
there
is
more
than
one
should
we
have
an
array
I
would
say
doing
this
will
make
it
super
hard
to
vary
by
something
at
all
right,
because
you
you,
it
will
be
harder
to
say.
Okay,
I
want
everything
for
this
tenant
or
everything
for
this
namespace.
You
can
only
query
by
the
whole
thing.
Probably
so
probably
should
not
do
it.
I
F
Yeah
I
mean
I
I
I
also
agree
with
clemens
here.
I
think
in
this
generic
part.
You
should
also
design
for
like
simplicity,
and,
I
think,
yeah
when
we
say
okay,
we
have
like
a
destination
name
or
node
name
or,
however,
we
might
call
it
to
be
as
generic
as
possible
and
believe
then,
the
more
specific
stuff
for
the
metal
system.
Specific
extensions
like
with
here
anyway.
Like
then
rabbit
they
can
add
their
routing
key
and
kafka
can
add
like
a
partition
number,
but
for
the
generic
for
the
generic
part.
F
You
have
like
an
end
point
and,
like
you,
have
several
kind
of
queues
as
notes
on
this
endpoint
or,
as
you
said,
with
parser,
there
might
be
different
kind
of
levels
and
I
think
the
destination
name
that
we
give
here.
It's
just
basically
the
the
last
leaf
leaf
node,
the
name
of
the
last
leaf
node
in
this
kind
of
whole
tree
identifying
identifying
the
the
destination,
and
it's
the
name
of
the
last
leaf
node
that
we
give
here
in
destination
and
any
additional
detail
can
then
be
specified
in
a
messaging
system.
Specific
way.
E
E
No,
so
end
point
should
go.
I
suggest
to
the
generic
span.
Attributes
like
not
your
name,
but
if
you
have
a
tree
in
within
the
send
point
like
pulsar
has
tenants,
there's
name
space,
slash
q
and
they
they
even
have
this
string
somewhere,
you
can
get
it.
I
think
they
provide
it
in
the
documentation.
E
E
D
For
example,
if
I
have
two
spans,
I
want
to
know
if
they're
sent
to
the
same
destination,
then
if
I
just
use
this
attribute,
I
cannot
do
it
right
because
they
will
have
the
same
exchange
name
but
different
routing
key.
Then
I
have
to
know
how
to
look
for
these
other
other
attributes
that
describe
the
destination.
E
J
The
the
constraint
there
or
the
problem
there
is
that
these
that
routing
key
is
a
special
simplification
of
this,
where
in
many
systems,
you
have
multiple
attributes
that
are
also
typed,
which
are
further
qualifying
the
the
message
like
if
we
care
about
metadata,
if
we,
if
we
care
about
about
putting
metadata
into
into
the
into
the
context,
information,
etc,
then
you
know
the
question
is:
where
does
that?
Stop?
J
Because
if
I
add
five
fields
that
describe
the
message
for
the
infrastructure
so
that
I
can
go
and
run
a
message
selector
over
those
five
fields,
do
I
need
to
include
all
five
I
said.
Routing
key
is
just
is:
is
a
simplified
variant
of
that
sort
of
metadata,
and
it
just
happens
to
be
that.
That's
because
there
is
a
feature
constrained
in
rabbit
and
q,
older
versions
that
it
just
can't
do
any
better.
J
I
I
agree
with
what
you're
saying
clemens,
but,
but
one
subtle
difference
I
think
too,
which
which
is
maybe
an
argument.
The
other
way
is
that,
in
the
case
of
the
routing
key,
if
I
understand
correctly-
and
I
I've
never
used
rabbit
personally
but
from
what
I
understand
about
it,
the
writing
key
is
explicitly
there
for
the
purpose
of
directing
the
message
somewhere,
whereas
in
jms
user
properties
may
be
used
to
determine
where
the
message
ends
up,
but
they
may
also
be
used
for
just
generic
attaching
metadata
to
messages
yep.
F
No,
I
think
we
shouldn't
decide
about
whether
definitely
not
we
are
I'm
sorry.
We
are
over
time
already
yeah.
So
thanks
everybody
for
participating.
This
was
a
great
discussion.
F
I
will
try
to
summarize
some
results
and
or
some
open
questions
here
in
the
pr
next
to
ludmila's
comments
here
and
maybe
please
feel
free
to
then
comment
and
add
your
your
ideas
or
your
objections
here
and
then,
let's
continue
discussing
this
week,
all
right
thanks
everybody
and-
and
if
you
have
time
please
review
or
approve
the
context
publication
pr,
so
the
camera
merged.