►
From YouTube: 2022-07-14 meeting
Description
Instrumentation: Messaging
B
B
D
B
D
Because
I
will
basically
be
out
for
the
next
one
and
a
half
months
and
I
put
in
the
in
the
slack
channel,
I
asked
whether
anybody
in
the
in
this
during
this
time
would
be
able
to
to
facilitate
these
meetings
and
trau
kind
of
said
he
will
be.
He
would
be
willing
to
do
that
and
yeah
thanks
a
lot
chao.
D
It
would
be
great
to
keep
like
keep
the
momentum
going
and
not
and
not
just
yeah
slack
cover
the
summer
and
then
have
to
completely
restart
in
autumn,
and
that
is
basically
I
I
put
some
things
here
for
just
next
items
that
I
think
would
be
needed
to
work
on
and
just
yeah,
maybe
to
get
I'm
not
sure
if
anybody
of
you
kind
of
wants
to
pick
any
of
those
in
particular,
but
I
think
the
last
one
is
anyway.
D
The
whole
group
basically
should
continue
the
discussions
about
the
general
attributes,
and
I
mean
the
goal
is
to
wrap
this
up.
I
think
it's
hard
to
me
just
to
estimate
how
long
that
might
take
they're
like
yeah
they're.
They
still,
we
are
still
not
wrapped
up
about
destination
and
there
are
other
kind
of
comments
thrown
into
pr
about
other
attributes,
so
it
might
still
take
a
bit.
So
I
think
that's
anyway
like
a
point
for
the
whole
group,
and
then
we
got
this
context
propagation
of
tap
merged
last
week.
D
So
that's
great.
Actually,
I
think
that's
the
first
kind
of
substantial
piece
that
we
as
a
group
produced
besides
the
initial
roadmap.
It
got
accepted
and
merged.
So
that's!
That's!
That's
really
great
thanks,
frau
again
for
also
driving
that
with
the
tc
and
what
would
be
a
next
step
here
would
basically
merging
like
the
content
of
this
old
tap
into
into
the
spec.
D
I
think
it's
not
much.
It's
also
not
very
controversial.
It's
basically
just
this
section
here
the
proposed
addition
to
the
semantic
conventions
which
is
kind
of
this
explanation
here
and
then
those
normative
requirements
here.
I
think
the
idea
would
be
to
kind
of
yeah
put
that
into
into
the
spec.
D
If
somebody
would
want
to
open
this
back,
pr
that'd
be
great,
because
I
I
personally
think
we
should
not
wait
too
long
from
like
the
approver
from
this
old
tap
to
putting
it
into
the
spec,
because
now
the
people
who
reviewed
the
old
depth,
they
kind
of
know
more
or
less
what
is
about
they
work
to
the
other,
and
then
they
can
also
prove
to
stack
work
as
compared
to
when
we
do
this
in,
like
two
months,
the
people
who
reviewed
the
old
debt
might
have
here
forgotten
about
that,
and
then
we
might
have
here
the
same
discussions
again
then
putting
that
into
the
spec.
D
D
I
will
try
to
come
up
with
a
with
a
draft
pr
still
this
week
for
that
kind
of
laying
out
the
difference,
the
what
they
came
up
with,
and
also
our
motivations
but
yeah.
That
would
also
be
then
a
work
item
discussing
this
in
the
group
incorporating
changes
into
the
pr-
and
maybe
I
think
for
this-
for
this
task.
D
It
would
be
crucial
to
get
also
some
kind
of
feedback
and
support
also
from
one
or
more
tc
members
who
will
then
help
us
kind
of
help
us
drive
this
through,
because
that's,
I
guess,
much
more
controversial
than
than
the
context
propagation
pr.
D
So
those
are
kind
of
your
three
next
steps
that
could
be
worked
on
in
the
summer.
You
are
not
sure
who
has
the
cyclist
and
the
willingness
to
then
yeah
to
to
devote
some
time
to
any
of
those,
but
you
just
wanted
to
put
this
out,
but
I
think
yeah,
the
the
the
least
that
would
be
great,
is
if
the
group
could
just
keep
going
on
the
discussions
about
the
attributes
where
we
are
now
and
if
anybody
has
additional
cycles.
D
E
D
E
B
D
Changes
required
for.
D
I'm
here
you're
talking:
are
you
talking
about
this
context,
propagation
out
tab
or
the
spam
structure?
Yes,
so.
B
We
have
the
authentic
it
was
merged
right
and
then
suggested
to
update
the
specific
stack.
Yes,
so
what
kind
of
changes
do
you
think
will
be
in
the
spec?
Because
of
this.
D
I
think
what
will
bring
the
spec
will
will
basically
be
this
here.
It's
like
the
section
that
we
have
this
proposed
addition
to
the
semantic
conventions
which
boils
down
to
those
requirements
here,
those
normative
requirements.
It
doesn't
really
change
much
like
it's,
not
a
breaking
change
for
respect
because
those
requirements
are
there
implicitly
anyway.
D
So
it's
just
about
kind
of
getting
this
explicitly
explicitly
mentioned
there.
I
think
that
we'll
having
this
made
clear
here
will
help
us
with
the
span
structure,
book,
tap
and
work
and
yeah.
That's
what
goes
into
the
spec
the
future
possibilities
which
are
more
controversial,
that
that
just
stays
in
the
old
tap
and
will
then
be,
I
think,
summarizes
some
of
our
thoughts,
but
this
will
then
be
some
some
future
work
still
but
yeah.
What
goes
now
into
the
spec?
It's
it's!
It's
basically,
this
here.
B
So
it
will
not
drive
any
instrumentation
changes
yet.
D
E
B
E
I
will
open,
I
will
take
a
look
at
this,
maybe
not
this
coming
week,
but
probably
the
next
one,
but
then
I
will
I
will.
I
will
send
a
link
on
the
on
our
slack,
so
you
guys
can
take
a
look
because
I
think
the
other
members
they
probably
will
wait
for
some
approvals
from
from
some
of
us
first
and
then
they
guess
they
feel
more
comfortable.
If
at
least
we
have
an
agreement
between
us,
I
guess.
D
Yes,
that
sounds
that
sounds
great,
because
I
think
that
was
also
basically
some.
I
thought
it
mentioned
with
with
this
old
tip
too,
that
people
in
the
dc
said:
oh
yeah,
the
the
messaging
work
group
has
an
agreement
on
that.
Please
have
a
look
at
it,
so
I
think
it
makes
sense
that
we
first
kind
of
approve
and
then
and
then
we
ask
other
people
to
prove
and
merge,
but
yeah
thanks
thanks
for
all
for
taking
this
over.
D
So
if
we
would
be
able
to
wrap
up
that
that'd
be
great
and
yeah,
then
for
the
for
the
whole
group.
Basically,
we
discuss
then
basically,
there's
this
continuous
discussion
about
attributes
in
this
old
tip.
I
will
see
how
far
I
get
before
I
go
on
vacation
and
put
up
a
physical
drafts
pr
and
then
yeah.
E
No
problem
yeah,
like
I
said
I,
I
am
probably
the
least
most
experienced
on
all
the
messaging
systems,
but
I
I
I'm
glad
to
help
facilitate,
at
least
for
collecting
the
thoughts
and
maybe
updating
the
pr.
But
I
I
still
rely
on
the
on
the
shoulders
of
other,
the
other
experts
that
that
usually
join
so.
D
The
group
here-
okay
awesome,
so
for
this
by
the
way
I
also
before
I
head
out,
they
tried
to
respond
to
our
comments
on
the
big
on
this
big
draft.
Pr
that
we
have
so
there
were
lots
of
discussions
going
on
the
partly
very
old
old
comments
I
didn't
get
to
answer
to.
I
tried
to
kind
of
answer
to
all
of
those
and
yeah.
D
Maybe
you
can
enclose
discussions
so
that
kind
of
we
have
an
easy
overview
of
what's
still
open
so
yeah,
maybe
if
you
have
had
some
open
commands
and
just
look
whether
what
the
road
is
satisfying.
Otherwise,
you
can
like
open
these
carton
items
again
and
yeah.
I
would
say:
let's
then
jump
into
it
and
continue
this
attributes
discussion.
D
I
think
we
were
last
time
talking
about
the
destination.
D
Destination
attributes
still,
we
were
basically
looking
at
all
those
different
systems,
and
I
think
I
made
this
proposal
here.
That
is
the
okay.
We
have
destination
name
and
destination
url
and
url.
Basically,
those
we
can
put
the
server
address
in
there
that
almost
every
messaging
system
has
and
then
ludmilla
brought
up
that
destination.
D
Url
is
probably
not
the
best
point,
because
we
also
have
this
net
net
peer
host
attributes,
where
that
would
be
better
suited
for,
like,
for
example,
for
server
names
like
here
that
we
connect
to
so
I
think
we
still
didn't
get
to
to
to
a
satisfying
conclusion.
C
I
don't
think
this.
This
is
a
right
assumption.
At
least
there
are
multiple
options,
so
their
destination
name,
at
least
currently,
is
the
topic
or
queue
name.
D
C
C
D
D
I
think
the
meaning
of
this
destination.name
if
we
expand
it
a
bit
that
it
just
just,
doesn't
need
to
map
on
concept
or
name
topic
and
queue,
at
least
for
me.
It
seems
there's
something
in
every
system
that
it
can
map
to.
I
mean
in,
for
example,
in
google
pops
up,
there's
a
topic
id
in
the
aws.
C
I
think
well
maybe
I
should
check
again,
but
when
I
looked
at
the
amazon
things
like
let's
test
and
google
something
they
were
like
one
host
things
anyway,
I'll
I'll
check
again
and
still,
if
even
if
they
all
have
something
like
this,
I
don't
know.
Even
the
greeting
measure
doesn't
have
anything
like
this.
C
You
just
have
a
host
and
you
send
everything
to
this
host
and
even
if
they
all
have
it
still,
it
would
be
nice
to
reuse
some
common
attributes.
C
D
D
This
is
an
interesting
take.
I
mean
that
is
kind
of
that
would
be
like
a.
C
D
Yes,
I
I'm
personally,
I
would
need
to
think
about
it
more.
I
I
think
something
like
this:
the
destination
or
destination
to
name
should
be
required,
and
I
I
I
mean
I,
but
I
agree
with
you
that
that
the
other
host
beaten
up
your
name
or
that
sock
pure
name
or
address
that
one
of
those
should
always
be
filled
when
possible.
C
Yeah,
so
the
the
net
per
name
is
the
one
that
the
most
useful
there.
So
if
you,
your
connections
through
proxy,
you
can
think
about
other
attributes
or
maybe,
if
you
have
just
an
ap
address
or
connection,
then
you
can
set
the
peer
socket
things,
but
basically,
let's,
let's
postpone
this
conversation,
it's
handled
by
the
general
conventions.
I
just
merged
this
change
about
those
attributes,
so
let's
general
conventions
take
care
of
it.
Let's
agree
if
we
need
this
logical
net
network
name,
if
we
should
reuse
it
or
if
we
or
not.
D
F
As
you
can
say,
one
thing
about
using
netpure
name
to
imply
something
regarding
the
destination.
I
think
it's
typical,
the
netpure
name
would
be
the
destination
when
you're
publishing,
but
when
you're
receiving.
If
you
have
a
network
of
brokers
and
you
have
a
destination,
the
netpure
name
would
be
the
the
broker
the
consumer
is
connected
to,
but
it
may
not
be
the
destination.
F
So
we
have
to
be
careful
a
little
bit
about
how
we'd
use
netpure
name
in
regards
to
a
destination,
because
just
thinking
of
networks
of
brokers
and-
and
you
know,
messages
that
that
gets
sent
through
the
network.
It
may
not
be
that
the
peer
the
consumers
connected
to
is
also
the
destination
of
the
original
message.
C
D
E
D
We
didn't
drop
that,
but
we
didn't
like
get
to
kind
of
discussing
that
yet,
okay,
okay,
so
that
would
be
a
next
discussion,
discussion
topic,
but
also
there.
This
problem
is
the
same
because
you
have
your
basically
your
publisher,
where
you
set
destination,
attributes
like
net
pure
name
and
maybe
destination
name
to
give
the
queue
name
and
then,
on
the
other
hand,
on
the
consumer
side,
you
have
your
messaging.source
attributes
or
messaging
source
name
for
the
queue
name
and
also
the
netq
name,
and
those
might
be
entirely
different
from.
D
E
It's
it's
just,
I
guess
the
nature
of
of
this
right,
so
we
might
just
need
to
make
it
maybe
clear
that
this
that
could
be
the
case,
but
I'm
not
even
sure
if
that's
necessary,
because
I
mean
I'm
assuming
that
someone
that
is,
but
it
has
a
has
a
system
that
is
that
is
following
such
such
architecture
that
they
probably
know
this
already
right,
that
the
sender
is
different
and
but
the
producer
sends
to
something
that
is
different
than
what
the
consumers
get
from.
E
What
would
be
confusing
is
that
we,
if
we
use
the
same
destination
like
massive
destination
for
consumers
and
produce,
I
think
that
will
be
confusing.
But
if
we
split
them
like
we
decide,
then
I
think
I
think
we
should
be
fine.
They
don't
match.
D
Maybe
we
will
need
to
to
look
more
still
more
into
that
ludmilla.
I
wonder
whether
you
could
I
mean
I
would
be
interested
in
your
opinion
whether
you
think
that
we
can
messaging
the
destination.name
like
the
mapping.
I
kind
of
tried
to
do
here
and
it
seemed
to
me
it
can
be
mapped
to
some
concept
in
every
of
the
system
we
came
up
with
here.
D
Maybe
you
can
verify
that
whether
that
makes
sense
for
you
and
when
you
already
said
that
for
azure
event
grid
actually
does
it
does
not
make
sense
there
is,
will
not
really
be
something
that
we
can
map
to
a
destination.
C
Yeah
and
let
me
uh-huh
sure-
and
let
me
try
to
revisit
this
systems,
because
I
was
under
impression
that
a
few
of
them
don't
have
a
notion
of
topic
for
q
and
let
me
try
to
come
up
with
proposal
how
each
of
them
would
map
to
this
proposal.
I'm
making.
D
Yes,
because
you're
first,
I
think
maybe
you
can
have
a
look
at
the
list
here
and
see.
If
everything
I
have
is
correct,
I
mean
yeah,
we
should
then
add
azure
service
grid
and
and
then
and
then
yeah
maybe
get
a
clearer
picture
of
of
whether
we
feel
good
about
making
messaging.destination.name
actually
required.
E
E
I
just
have
one
question
about
this,
about
the
comment
that
you
have
there
a
bit
down
about
the
message:
specific
attributes.
I
think
the
one
actually
asks
something-
and
I
I
think
I
I
understood,
but
maybe
we
should
clarify
like
if
there
is
a
for
example,
if
for
for
azure,
that
there
is
this
or
for
for
amazon
that
has
this
namespace
attribute
should
be
like.
E
Messaging.Messenger.Destination.Aws.Namespace
or
things
like
this
or
because
I
think
that's
what
do
duane
mentioned
in
one
of
his
comments.
It
was
not
that
it's
not
not
clear,
because
I
don't
think
it
will
be
good
if
we
mix
like
provider
specific
attributes
in
the
name
space
of
and
from.
E
D
E
D
C
It
would
be
just
the
same
and
I
I
don't
think
we
would
ever
need
the
namespace
and
maybe
for
aws.com
is
the
network
name,
because
this
is
how
they
identify
their
resources.
But
maybe
not
that
probably
amer
has
more
experience
with
it
than
me,
and
many
other
people.
E
Yeah,
I
think
it
was
just
more
more
more
as
an
example.
If
we
have
attributes
that
is
specific
to
some,
how
we
would
lay
there
them
out.
But
yes,.
C
Oh,
by
the
way,
it
sounds
like
regardless,
whether
it's
messaging
for
its
database
or
any
amazon
service,
things
like
account
and
region
would
be
cross-path,
and
we
probably
should
not
introduce
such
things
in
messaging
conventions,
and
we
can
say
if
amazon
had
such
conventions
somewhere,
we
can
refer
to
them.
D
For
aws
related,
yes,
I
think,
if
I
think
they
already
probably
maybe
have
similar
concepts
already
in
other
aws
specific
semantic
conventions,
and
I
think
it
would
then
be
up
to
them
to
kind
of
come
up
with
consistent
attributes
and
maybe
you're
right,
probably
those
those
account
then
and
region
will
not
be
in
the
messaging
name
space
but
might
be
reused
from
some
different,
maybe
global.
Maybe
it's
just
aws
dot
account
and
aws
dot
region
globally.
That
is
reused.
F
My
thinking
of
this
discussion
is
the
goal
is
to
specify
how
you
might
extend
the
destination
attributes
for
a
system
without
trying
to
suggest
what
we
should
do
for
any
particular
system
and
like
so
maybe
the
examples
here
aren't
good,
and
maybe
we
should
shy
away
from
specific
examples
and
just
say
if,
for
a
particular
system,
there
are
additional
attributes,
you
know
associated
with
the
destination
that
it
should
start
with
a
system
identifier
and
embed
additional
things
underneath
that
system
identifier.
D
Yes,
I
I
agree.
Actually,
I
think
the
examples
here
only
wanted
to
give
to
show
what
could
potentially
be
done,
but
that's
you
know,
I
don't
see
them
in
any
way,
as
some
kind
of
suggestion
of
how
things
actually
should
be
done,
so
I
think
the
only
thing
about
it.
Basically,
the
show
is
that
we
have
maybe
this
generic
destination
name
and
then
the
other
system
have
something
that
they
can
put.
On
top
of
this.
E
B
E
B
F
I
think
it
probably
wouldn't
necessarily
matter
to
the
specs,
because
I
think
it
would
be
up
to
like
a
separate
kafka
spec
in
terms
of
how
kafka
should
extend
this
spec
to
include
the
relevant
information.
You
could
almost
make
an
argument
that
the
the
key
should
be
part
of
it.
That
could
be
a
very
large
or
you
know
blob,
so
that's
probably
not
suitable,
but
I
don't
know
if
this
spec
would
would
dictate
what
what
any
particular
messaging
system
should
do.
D
No,
no,
I
think
the
main
question
we
should
answer
here
is
that
is
there?
Is
there
anything
in
terms
of
destination
that
they
can
make
general
for
our
messaging
system?
Is
there
this
destination,
maybe
dot,
name
that
we
have
and
that
we
can
kind
of
meaningfully
meaningfully
kind
of
give
a
value
for
all
different
systems?
D
I
think
that's
the
main
question
we
should
answer
and
then
basically,
on
top
of
that
kind
of
let
other
systems,
let
all
the
individual
systems
kind
of
add
additional
things.
C
Yeah-
and
it
would
be
nice
to
have
some
idea
about-
I
think
we
had
this
discussion
before
so
there
is
partition
not
for
just
kafka,
leisure
event,
hub
support
partitioning,
but
there
are
also
this
pulsar,
I
think
or
not
they.
They
have
a
tree
like
structure
of
tenants
and
name
spaces
and
so
like
when
we
talk
about
destination
name,
are
we
talking
about
the
final
thing?
C
The
whole
thing,
or
we
are
talking
about
some
specific
thing
and
in
case
of
partitioning,
for
example,
for
event
hub
partitioning,
really
matters
only
on
the
consumer
side,
so
producers
don't
even
need
to
specify
partition
and
if
we
don't
specify
some
conventions
regarding
the
destination
name
and
source
name,
we
put
a
number
in
the
situation.
Where
ended
up
now,
where
we
on
the
producer,
we
put
the
pew
name
on
the
consumer,
we
put
queue
plus
partition
and
they
don't
match
right.
So
it's
not
a
great
user
experience
and
it's
hard
to
find.
C
B
C
E
Yeah,
I
think
so.
Yes,.
E
B
B
B
C
B
C
You
want
to
specify
that
messaging
destination
is
the
standard,
and
then
anything
that
goes
after
it.
C
E
B
Yes,
so
if
like
messaging
specific
destination,
attributes
will
contain
the
destination
database
key,
then
we
can.
B
C
Yeah,
I
still
need
to
know
about
routing
key
to
put
it
in
the
right
place.
I
mean
if
you
have
messaging
destination
dot,
something
does
something
you
still
need
to
know.
What's
in
there
to
visualize
it
now
or
maybe
you
can,
you
can
like
specify
what
exactly
what
you
want
to
do.
So
we
can
have
an
idea.
B
D
I
don't
have
a
strong
opinion
there
either,
but
I
think
yeah
that
will
then
be
up
to
the
individual
systems.
Basically,
I
would
leave
that
up
to
them,
then
to
can
up
with
like
a
meaningful
solution
here
but
yeah.
I
think
the
reiterate,
I
think
what
we
should
try
to
figure
out,
and
maybe
a
people
can
think
about
this,
something
like
time,
whether
yabby,
whether
we
can
agree
on
that
we
have
this
one
kind
of
generic
destination
name
across
our
systems
and
we
are
able
to
kind
of
give
this
a
meaningful
value
for
our
systems.
D
I
think
if
we
could
agree
on
that,
then
we
could.
Then
we
could
say:
okay,
this
destination
name
is
required
across
all
systems
and
then
each
system
kind
of
here
can
extend
it
by.
I
will
try
to
keep
this
up
here
because
yeah
that
I
think
it
causes
more
confusion,
this
command.
Then
it
clarifies
things,
but
that
then
we
say:
okay,
then,
in
addition
to
this
name,
that's
generic
followed
for
all
systems.
There
is
kind
of
additional
system,
specific
attributes
and
there's
also
net
peer
name,
of
course.
B
D
I
think
the
kind
is
a
separate
destination
topic
yeah
I
mean
it
might
actually
be
part
of
the
uniquely
identified
upper
destination
name
when
there
is
any
kind
of
system
that
offers
different
kinds
and
allows
you
to
have
same
names
for
those
different
kinds.
I
don't
know
about
that,
but
I
think
you're
kind.
We
should
then
discuss
separately.
D
But
I
will
try
to
reformulate
this
comment
with
what
we
said
here
that
yeah
we
try
to
think
about
this
messaging
destination
name
and
that
roby
kenya
basically
said
give
give
this
a
meaningful
value
for
all
messaging
systems
that
we
that
we
come
up,
that
we
can
think
about.
D
D
We
can
update
that
and
there's.
There
was
one
more
comment
here
from
duane,
where
this
is
related
to
the
to
the
basically
the
messaging
source,
but
we
said
okay
also
for
messaging,
basically
for
the
for
the.
D
For
the
consumer
we
might
have
both
we
might
have
messaging.source
and
messaging.
The
destination
source
is
basically
where
the
consumer
receives
it
from
and
destination
is
where
the
producer
originally
sent
it
to-
and
I
think
duan's
main
point
here
was
the
destination
you
might
not
have
all
the
information
at
the
consumer
side
to
give
order
to
to
give
all
the
attributes
that
make
this
original
destination
unique,
identifiable
and
yeah.
I
I
said
yeah
we
should
be
fine
with
having
partial
information
here.
D
If
we
don't
know
everything,
then
it's
fine
to
just
give
powerful
information.
We
don't
require
this
this
destination,
on
the
on
the
consumer
side
to
be
uniquely
identifiable.
D
Okay,
so
that
is
basically
an
open,
still
an
open
item,
so
we
will
yeah
basically
looking
to
weather
this
destination.name,
whether
we
can
make
this
required-
and
I
will
I
will
add
a
comment
here
and
there
has
been
quite
some
discussion
about
this
template
attribute.
I
think
we
have
here.
D
50
minutes
left
or
you
are
30
minutes
left.
We
could
start
trying
to
start
to
get
some
to
to
discuss,
to
discuss
this
and
get,
if
not
some
clarity,
maybe
try
to
get
on
the
same
page
or
try
to
get
closer
to
being.
On
the
same
page
about
this,
I
try
to
sum
up
some
thoughts
here
that
ludmilla
looked
into
several
systems
and
said
that
basically
two
nets
and
mqtt
they
have
they
call
it.
D
Wildcard
kafka
and
pulsar
call
it
pattern
and
we
came
up
with
the
term
template
here
and
then
duane
suggests
different
terms.
An
additional
term
schema.
So
we
have
that.
D
We
have
basically
here
four
terms
floating
around
pattern,
pattern,
wildcard,
template
and
schema
and
for
similar
concept,
and
I
think
it's
worth
discussing
for
us
in
how
how,
in
how
far
we
want
to
support
this
concept
in
a
generic
manner
anyway,
because
from
all
the
systems
we've
seen
above,
there's
basically
one
two
three
four
that
support
it,
which
is
kind
of
yeah,
not
the
majority
of
systems,
and
I
think
the
first
question
is:
do
we
want
this
kind
of
a
first
class
messaging
system
independent,
attribute
capturing
this
template,
because
another
option
would
just
always
be
to
just
have
it
like
a
messaging
source,
dot,
kafka.pattern
or
messaging.source.net.wildcard.
D
F
So
I'd
like
to
explain
what
I
think
the
importance
of
this
is
and
why
it
should
be
part
of
the
specification,
and
it's
because,
like
it
comes
down
to
does
a
messaging
system
have
a
high
cardinality
destination
space
and
I
think
systems
like
kafka.
Don't
right
like
a
a
topic,
is
a
configured
thing
on
a
broker,
and
so
you
would
never
put
like
gps
coordinates
or
something
inside
of
a
kafka
topic
right.
F
You'd
have
to
configure
a
topic
on
a
broker
for
every
single
possible
coordinate
and
that
doesn't
make
any
sense
in
those
messaging
systems.
And
so,
if
you
have
a
high
cardinality
topic
space
in
a
system,
I
think
it's
a
possibility
of
using
it
as
part
of
a
span
name,
and
we
said
we're
gonna
kind
of
do.
We
started
talking
about
spam
names
quite
a
while
ago,
and
we
said
well,
it
seems
like
we
have
to
decide
on
attributes
first
and
then
come
back
to.
A
A
Yeah
so
maybe
join
can
drop
and
rejoin,
and
I
can
perhaps
carry
on
his
argument
while
he's
gone
so
yeah.
I
think,
as
wayne
said,
it's
a
primary
concern
about
naming
the
spans.
You
know
creating
some
sort
of
low
cardinality
thing
where
you
can
actually
have
include
either.
You
know
the
actual
topic
in
the
case
of
kafka
or
this
topic
pattern
in
the
case
of
in
the
case
of
something
that
allows
wild
cards
like
solace
and
like
mqt
and
such
as
that.
A
So
it's
a
useful
topic
and
it
also
aligns
well
with
async
api,
which
has
the
the
concept
of
these
channels,
which
are
essentially
you
know
physically
implemented
as
as
topic
strings
and
allows
for
parameterization.
So
it
creates
a
sort
of
nice
interchange
between
open,
telemetry
and
async
api
and
also
open
api,
which
also
allows
sort
of
parameterization
in
that
way.
So
it
I
think
technology
wise.
It
creates
a
lot
of
interesting
interchanges.
F
Yeah
and
I
think
just
to
expand
on
that-
my
hope
was
that
if
we
agreed
on
something
like
this
in
the
attributes
that
we
might
come
up
with
a
rule
like
in
the
span
name,
if
the
messaging
system
has
a
low
cardinality
topic
space,
you
can
use
the
topic
if
it
doesn't,
and
this
template
exists,
then
that
could
substitute
in
instead
of
the
topic.
But
if
we
don't
have
something
like
this,
then
messaging
systems
that
have
high
card
nowaday
topic
spaces
kind
of
can't
put
any
of
this
information
in
in
any
way.
F
C
C
What
I
think
that,
even
if
there
is
no
concept
like
this
on
the
messaging
system,
but
if
users
use
it
in
the
way
that
they
put
high
cardinality
things
in
there,
some
advanced
users
would
really
benefit
from.
I
don't
know
configuring
this
template
or
providing
some
this
in
some
custom
way.
We
don't
know
how,
but
let's
figure
it
out
later,
if
we
can
specify
it
as
a
general
case
thing,
and
there
are
plenty
of
systems
that
support
it
right.
D
I
think
that
would
also
make
the
the
kind
of
definition
of
what
what
what
what
to
put
into
the
span
a
much
more
much
easier
and
transparent.
D
F
F
It
doesn't
imply
high
cardinality
topic
space,
but
so
anyways
it
it
it's
useful,
maybe
if
you're
using
wild
cards,
but
it
also
isn't
really
describing
wild
cards.
It's
sort
of
describing
things
that
consumers
might
wild
card
perhaps,
but
I
think
it
is
really
just
describing
your
topic
that
you're
publishing
on
where
there
may
be
values
like
just
that
are
basically
variable
substitutions
kind
of
like
a
show
like.
Maybe
you
have
a
vin
and
a
gps
coordinates
or
something
in
a
topic,
and
it's
just
sort
of
describing
well
what
it?
C
Yeah,
thank
you
for
the
context
and
I
don't
have
a
super
strong
opinion.
I
think
template
is
fine.
I
think
my
problem
was
that
I
was
trying
to
find
what
it
means
in
different
systems
and
there
was
just
nothing.
So
maybe
it's
a
documentation
thing
and
when
we
document
this
attribute,
we
say
this
is
what
it
is
called
on
this
systems
and
maybe
give
some
links
and
then
others
I
don't
know.
If
I'm
working
on
some
random
system,
I
can
come
and
understand.
C
D
I
think
so
too.
We
couldn't,
for
example,
mention
that
we
have
this
template,
which,
in
my
opinion,
from
the
from
the
four
possibilities
we
have
to
me,
seems
like
the
like,
the
like
the
best
term,
but
whatever
we
name
it,
you
could
say:
okay,
we
have
this
destination
and
source.template,
and
for
nets
and
mqtt
you
put
in
their
bots
during
wildcard
for
kafka,
pulsar
you
put
in
what's
in
pattern
and
for
all
other
high
cardinality
topic
or
q
names
you
you
just
put
in
like
a
feasible
kind
of
generic
name.
D
For
that,
if
it
exists,
I
think
that
could
be
then
the
the
the
documentation,
maybe
with
some
with
some
like
examples
that
also
dwan
gave
here,
and
I
think
that
might
be
might
make
it
more-
might
make
it
clearer
what
this
template
is
supposed
to
be.
F
Yeah,
I
just
don't
think
you'd
actually
use
a
a
wild
card
per
se
here
because,
like
a
wild
card,
might
look
like
star-
or
you
know,
pound
for
mqtt
like
it
it
wild
cards
describe
what
you
part
you
don't
care
about,
but
it
doesn't
give
it
a
name,
and
so
I
think
it's
more
an
application
layer,
knowledge
of
the
topic
space
that
you're
injecting
into
this
message
or
in
the
case
of
async
api.
F
It's
actually
not
application
layer,
it's
good
that
they
put
this
as
part
of
the
api
itself
that
so
you
could
auto
instrument
the
api
to
do
it.
The
tricky
part
with
many
existing
systems
is
that
it
would
be
up
to
the
application
to
inject
this.
The
system
itself
doesn't
know
this,
and
so
I
I
presume,
that's
possible
that
once
a
span
is
started,
the
application
might
be
able
to
add
an
attribute
to
the
current
span.
I
think
that's
that's
possible.
I
believe.
E
Yes,
yeah
yeah,
okay,
but
but
the
name
you
know
if
you
want
to
use
the
name
that
it
needs
to
know
on
the
span
creation,
but
yeah
and
spam
can
be
updated.
F
F
C
E
E
Yeah
they
call
it
route,
but
in
the
table
they
say
the
magic
route
path,
template.
F
So,
just
look
at
that.
There's
look
at
the
nats
example
and
and
there's
one
in
there
that's
time
dot,
star
dot,
east.
The
problem
is,
it
doesn't
say
what
star
is
if
you,
if
you
have
a
in
this
case,
you
might
assume
based
on
the
structure.
It
probably
is
the
time,
but
that's
not
always
the
case
with
all
topic
hierarchies.
F
This
is
an
example
like
position,
slash
latitude
longitude,
you
know
you
might
assume
those
two
values
somehow
mean
position,
but
some
sometimes
topic
hierarchies
will
be
written
in
a
way
that
you
can
guess
a
bit,
but
I
think
the
ability
to
actually
put
text
to
describe
what
that
level
is
is
useful
and
it's
not
the
wild
card
itself
that
you're
interested
in.
D
I
think
that
comes
from
the
that
information
probably
comes,
then
from
some
context
that
the
person
who
views
it
it
has-
I
mean
I
I
I
agree
that
it's
definitely
kind
of
preferable
to
have
it
like
this
gps
latitude.
D
But
I
think
also,
if
you
have
like
the,
if
you
know
what
you're
looking
at
you
might
also
be
able
to
infer
from
the
star
that
it
is
the
latitude
and
the
thing
that
might
be
useful
for
nets
and
mqtt.
F
The
problem
with
that
is
that
those
wild
cards
apply
on
the
consumer
side.
The
publisher
never
specifies
these,
and
I
think
it's
primarily
on
the
published
side,
where
it'd
be
of
the
most
of
most
use
and
yeah.
F
Yeah,
yes,
unless
you're
using
something
like
async
api,
where
it's
it's
all
part
of
the
channel
definition.
Jesse
is
much
more
plugged
into
some
of
this
stuff
than
I
am,
but
where
we,
where
a
lot
of
this
stuff
is
going,
is
people
are
building
systems?
F
On
top
of
you
know
the
kind
of
legacy
messaging
because
they
need
to
catalog
and
maintain
and
provide
implement
policy
on,
and
so
they're
built,
they're
kind
of
cataloging
their
event
categories
stuff
like
that,
and
then
that
kind
of
information
goes
into
these
newer
apis,
like
async
api,
and
so
it's
sort
of
like
more
of
a
self-documenting
api
and
and
so
for
people
using
stuff
like
this
auto
instrumentation
for
an
async
api
implementation
could
put
all
of
this
directly
in
there.
F
If
you're
using
more
of
a
lower
level
legacy
system,
then
yes,
it
would
require
application
cooperation
to
to
put
this
into
the
span.
D
Okay,
we
are,
we
are
one
minute
over
time
now.
I
will
try
to
summarize
some
of
our
discussions
today
here
regarding
the
template
attribute
and
also
regarding
the
destination
name
and
then
yeah
maybe
comment
on
that
think
about
it
until
next
week
and
then
next
week,
the
discussion
can
can
continue
on
that.
B
B
So
if,
if
we
have
the
template,
then
we
can
use
the
template
for
the
filters,
but
if
not,
then
we
need
to
fall
back
to
the
destination
name
right,
but
is,
do
you
think
there's
some
like
a
generic
way
to
get
a
local
dentality
value
which
is
guaranteed
to
be
low?
Cardinality
like
if
I
see
the
template,
I
know
it's
low
cardinality.
If
I
don't
see
the
template,
do
I
know
if
the
destination
name
is
local
donality
or
white
cardinality.