►
From YouTube: 2022-09-08 meeting
Description
Instrumentation: Messaging
C
Make
solace
the
official
broker
of
open
telemetry
all
those
in
favor.
B
A
C
A
A
Yeah,
I
guess
I
can
see
it
better,
yeah
swag
from
a
conference
or
how
did
you
get
it?
I
think
I
got
a
gift
card
for
the.net
store.
A
A
A
A
A
So
I
wrote
here
welcome
back
johannes
good
to
have
you
back.
I
did
so
just
I
guess,
to
kind
of
help
you
and
and
also
to
help
us
as
well,
because
we
did
discuss
a
lot
of
things
in
this
period.
The
fear
that
you
were
away,
so
I
just
put
it
on
a
try
to
come
up
with
a
summary
of
everything
that
happened
and
everything
that
we
discussed.
A
So
I
put
it
all
here
in
the
agenda.
We
don't
have
to
talk
about
all
this,
but
about
all
of
it,
but
I
just
thought
it
would
be
good,
so
you
don't
have
to
go
through
all
the
meetings
and.
B
Things
like
that,
so
I
didn't
have
any
time
yet
to
catch
up
with
all
so
I'm
pretty
blank.
So
I
will
like
just
beat
a
fly
on
the
wall
today,
but
yeah
I
will.
I
will
catch
up
during
the
next
week
and
thanks
for
putting
the
summary
together.
That's
great.
A
No
no
worries
yes,
so
so
last
week
we
were
discussing
about
individual
messaging,
also
paired
message:
attributes
blood,
mila,
open,
open,
vr,.
A
Yeah,
so
just
a
summary,
so
so
we
we
we're,
not
completely
lost.
So
we
discussed
a
lot
about
so
we
started
discussing
the
attributes
when,
after
you,
we
continued
discussing
the
attributes
a
little
bit,
then
we
quickly
bumped
into
a
problem
where
we
found
that
there's
several
attributes
that
are,
we
knew
already
that
are
specific
for
us
for
for
a
single
message
like
the
message
id
and
and
so
on,
but
we
also
found
another
one.
A
That
is
the
destination
that
I
think
ludmila
was
the
one
that
found
that
in
kafka,
when
you
send
a
badge
can
also
a
batch
can
contain
messages
that
are
not
for
the
single
destination,
but
they
can.
They
can
be
shared.
So
in
the
same
batch
there
can
be
message
for
a
different
destination,
so
multiple
destinations
in
the
same
batch,
and
then
we
discussed
this
further
and
further
and-
and
this
kind
of
was
the
I
guess
the
trigger.
That's
what
I
put
in
the
notes.
A
There
was
a
trigger
of
we're,
discussing
message
per
message,
attributes
and,
and
then
amir
wrote,
the
wrote,
the
document
that
he
wanted
to
bring
up
as
a
old
dap
to
introduce
something
like
a
new,
let's
say,
name
space
in
the
attributes.
So
we
have
currently
messaging
dot
message
id
direct
like
this,
but
it's
not
possible
to
know
like
from
my
spin
if
this
pen
is
related
to
a
badge
or
if
it's
related
to
a
single
message.
A
So
then
we
discussed
about
this
a
lot
and-
and
so
this
was
one
aspect
of
it
and
then
ludmila
opened
spr,
because
we
wanted
to
to
start
doing
things
more
incrementally
instead
of
like
discussing
a
lot
and
then
only
then
bring
it
to
the
to
the
spec
to
the
broader
group.
So
we
we
thought
of
doing
this.
This
way
more
often,
and
then
ludwig
did
also
some
research
on
the
which
attributes
are
are
commonly
on
on
the
on
on
a
per
message
base.
A
A
There
you
go
so,
for
example,
we
now
have
or
proposed
to
have
messaging.master.conversationid
and
then
a
message.id
like
this,
and
we
also
discussed
about
having
for
the
badge
for
batch
as
well
a
different
name
space.
A
Exactly
yeah,
so
this
this
was
the
the
the
motive
for
this
because
yeah,
because
we
discussed
where
we
would
add
so
after
we
found
out
about
this
cafe.
Example,
we
were
a
bit
not
sure
where
we
would
add
message
individual
attributes
if
we
would
add
them
to
the
spin
or
we
would
add,
to
the
link
and
things
like
this
and
this
kind
of
spawned
this
work
and
we
kind
of
discussed
a
lot
with
canada.
We
actually
discussed
a
lot
about
the
context
or
the
creation
context
as
well.
A
A
A
So
then
we
we
discussed,
like
all
the
problems
that
we
already
know
like
zero
duration
and
and
and
what
not
about
using
a
spin
and
the
benefits
of
using
spam,
not
the
benefits
of
not
using
this
again
and
then
then,
thanks
to
her,
she
did
also
some
summary
and
laid
out
all
the
all
the
options
we
consider
so
there's
the
usual
with
the
full-fledged
spam
and
not
with
the
spam
and
edit
the
links,
adding
the
articles
to
the
link
and
and
all
that
stuff
so,
but
within
which
any
decision.
A
The
thing
that
we
did
reach
is
that
putimira
also
created
an
issue
to
discuss
about
this
topic
about
like
what
what
would
we
use
for
for
this
and
and
if,
if
we
use
a
span,
if
we
use
something
else,
if
we
come
up
with
a
new,
let's
say
spainless
context,
I
think
that's
what
something
term
that
we
used.
A
There
was
some
initial
traction
on
it,
but
it
kind
of
died.
Nobody.
Nobody
commented
much
on
it
anymore.
I
think
yeah
there
was
christian,
brought
the
point
of
maybe
considering
an
event
or
something
like
that,
but
yeah
the
the
the
current
convention.
They
don't
talk
about
events,
they
already
talk
about
links,
so
change
to
event
will
change
the
current
thing.
So
not
sure
if
that's
a
good
idea.
A
Yes,
I
think
that
was
pretty
much
like
the
big
chunk
of
things.
So
we
discussed
a
lot
about
the
context.
What
the
context
will
be
if
we
need
to
do
work
to
push
for
a
like
a
new
concept
that
we
don't
have
like
a
just
a
like
a
simple
context
or
no
attributes
context,
or
it
knows
spain
that
constant
painless
context
yeah
or
we
go
with
the
full
span.
But
then
we
have
all
the
other
problems
that
we
already
know
like
costs,
space
and
and
zero
duration,
and
things
like
that.
A
But
we
didn't
really
come
to
any
conclusion
and
then
the
the
discussion
where,
like
last
week,
specifically,
we
discussed
like
where
to
add
so
like
if
we
always
add
a
link,
for
example,
for
badges.
We
always
need
a
link
anyway,
but
do
we
always
need
a
link,
for
example,
what
what
we
do
in
single
message
scenarios?
Do
we
in
that
case?
Do
we
also
create
a
link
to
make
the
trace
the
same?
A
Always
and
not
have
like
a
different
different
way
of
doing
it
or
when
you're
dealing
with
single
messages
versus
when
you
deal
with
the
badge-
and
I
think
if
I
remember,
I
think
we
kind
of
lean
towards
not
to
using
links
for
a
single
message
message
scenarios.
But
then
we
also
thought
about.
But
where
would
we
put
the
attributes,
then,
in
that
case,
for
for
single
message
so
yeah?
But
I
think
that's
pretty
much.
B
A
Yes,
I
think
amir
also
had
some
concerns
about
having
this
distinction,
because
that
could
make
things
harder
for
for
backhands
and
so
on.
A
And
also
there
is
no
way,
for
example,
let's
put
the
thing
with
the
name
space
as
well,
when
this
a
new
attribute
that
we
also
thought
about,
having
like
some
attribute
to
identify
if
it's
a
batch
or
not
like
the
batch
size
or
something
like
this,
but
then
we
also
discussed
like
there
might
be
instrumentations
that
offer
single
message
apis
to
the
user,
but
in
the
end
they
actually
send
always
in
a
batch,
for
example,
and
that
in
that
case,
for
example,
it
will
be
batch
one.
B
One
question
after
this
here
like
this
for
this
per
message
attributes
the
first
point
says
that
that
ludmilla
found
out
that
a
badge
can
contain
messages
for
different
destinations,
but
is
it
but
destination?
Your
are.
You
is
the
goal
to
make
this
up
per
message
attribute
two,
because
I
think
that's
that's
not
enough.
Meters
power
is
at
least
as
far
as
I
saw
now,
it
seems.
Destination
is
still
a
a
general
attribute.
C
Yeah
we
didn't
decide
it
yet,
because
we
were
split
like
how
what
namespace
we
put
it
in
per
message
per
batch
or
without
any
message
or
batch
namespace.
A
The
idea
with
dpr
was
just
so,
we
start
doing
it
and
we
create
like
a
precedence
to
have
this
namespace
in
place
and
this
and
we
chose
to
chose.
I
guess,
that's
the
idea,
that's
why
I
understood
that
we
chose
the
most,
let's
say
controversial
ones,
but
we
can
at
least
have
the
idea
in
place
that
we
can
incrementally
add
more
and
more.
B
A
Yes,
apart
from
this,
I'm
just
going
quick,
but
I
will
have
time
to
catch
up,
so
I
just
want
to
give
a
quick
overview
and
then
I
opened
the
hotep
for
for
moving
the
I
opened
the
pi
to
move
the
old,
app
context
to
the
spec,
but
yeah
like.
A
I
think
we
still
need
approvals
on
our
side
first,
so
they
see
that
we
are
aligned
so
definitely
more
approvals
there.
I
guess
we'll
count
doors
in
our
favor,
but
then
riley
also
comment
that
they
need
more.
So
first
there
was
a
comment
in
my
information
and
I
was
a
little
bit
confused
because
I
didn't
know
what
more
information
was
needed,
but
that
would
not
be
the
issue.
A
So
I
put
the
asia
together
with
the
bi
and
then
there
was
this
label
applied.
I
was
really
confused
because
there
was
no
comment.
The
label
was
just
applied
so
then
I
asked
like
what
need
more
information
and
then
right.
I
just
mentioned
that
you
need
more
discussions,
and
so
so
I
ended
more.
I
basically
rephrased
everything
here
and
did
some
diagrams
and
so
on
and
I
joined
the
spec
call
as
well.
A
This
week
to
to
bring
it
up
there
to,
I
don't
know,
bring
more
folks
into
it,
but
then
there
was
this.
There
is
this
new
initiative.
A
Maybe
a
full
site,
but
there's
this
big
initiative
to
work
on
instrumentation
stability
and
all
semantic
conventions,
and
that's
like
it's
quite
massive
there's
a
lot
of
stuff
here,
yeah.
So
the
the
the
issue
here
already
mentioned
that
they
they're
gonna
focus
on
the
focus
on
this
now
and
they're,
not
sure
if
there's
enough
cycles
or
enough
enough
time
or
enough
dc
power
to
also
take
a
look
at
this
this
this
this
pr
that
I
opened
so
yeah.
So
this
is
the
status
right
now
for
it.
A
B
B
B
I
mean
it,
it's
it's
it's
good
in
a
way
because
then
one
keeps
the
the
more
like
how
to
say
bureaucratic
and
administrative
discussions
separated
from
the
technical
distractions,
so
yeah
yeah.
A
Yeah
so,
but
I
I
I
talked
with
armin
yesterday,
he
started
in
the
pc
meeting
yesterday.
They
discussed
this
there
and
I
think
they
agreed
that
because
it
was
already
an
agreed,
hotep
and
so
on.
So
maybe
they
will
be
able
to
look
at
this
again.
So
I'm
waiting
if
there
there
will
be
any
new
comments
here,
but
I
think
I
think
we'll
be
able
to
do
this.
B
But
I
agree
with
you,
I
think
from
our
side,
then
it's
kind
of
we
should
approve
and
agree
on
the
changes.
I
think
that
is
the
first
step
and
then
and
then
we
can
try
to
push
this
further
so
yeah.
I
will.
I
guess
this
will
be
one
of
the
first
things.
I
will
look
into
your
pr.
A
C
A
Give
a
little
bit
more
context
before
introducing
the
like
creation
context,
but
it's
it's
the
base.
It's
still
there
yeah
sounds
good.
A
Okay,
I
actually
didn't
put
anything
to
discuss.
I
just
wanted
to
give
this
overview
here.
C
A
A
Otherwise,
I
guess
maybe
we
could
take
a
look
at
the
message
discussion
as
well,
or
the
the
link
discussion.
C
I
have
a
question
about
this.
This
process
we
have
with
issues
versus
our
tabs,
so
the
odd
tab
we
have
merged.
It's
only
about
context
propagation
right,
yes,
which
means
that
if
we
want
to
merge
anything
else,
including
the
attributes
right,
the
clarify
in
the
namespace,
we
would
probably
have
a
hard
time
with
it.
A
A
I
think
I
also
heard
talks
about
having
new
semantic
conventions
being
backed
by
either
maintainers
of
the
project,
where
things
are
being
added,
for
example,
like
there's
this
reason
there
was
this
pr
from
adding
70
questions
from
our
apache
pulsar,
so
like
having
someone
from
apache,
pulsar
stamp
I'll,
say
now.
This
makes
sense.
This
is
this
is
good
but
yeah,
but
we
we,
we
might
have
problems
yes,
yeah
from
now
on.
B
I
mean
I
think,
as
far
as
I
saw
like
josh
from
google
he's
leading
that
initiative.
I
think
then,
at
some
point
we
just
need
to
maybe
sync
with
him
and
ask
how
he
as
a
group
can
continue
to
work
most
efficiently
because
there's
no
reason
kind
of
there's.
No,
we
should
avoid
like
blocking
each
other
like
overloading
them
with
work
that
they
cannot
do
and
they
kind
of
blocking
us
by
lacking
resources.
B
So
I
think
we
should
try
to
to
to
get
some,
maybe
guidance
from
him
of
how
of
how
best
and
most
efficiently
we
can
work
together.
There.
C
A
C
B
A
B
B
I
can
try
to
get
in
touch
with
josh,
maybe
I
mean
I,
ideally
he
can
make
you
to
one
of
our
meetings.
Otherwise
one
of
us
can
try
to
sync
with
him
offline
and
kind
of
just
see
how
best
the
best
we
proceed
there,
because
I'm
not
even
sure
whether
josh
is
aware
of
like
the
work
that
we're
doing
and
that
we're
doing
as
a
group.
So
I
think
it
would
just
be
great
to
create
we'll
be.
A
Yeah,
there's
all
these
issues
like
that
this
work
would
would
solve
or
tackle,
but
yeah
seems
like
it's
a
it's.
A
lot
of
like
base
like
luke
means
it's
like
a
foundation
or
something
like
that
on
things.
C
And
if
we
are
absolutely
completely
blocked
and
this
this
pack
we're
trying
to
create
one
get
merged
in
theory,
we
can.
I
don't
know
how
the
specification
country
people
and
put
our
stuff
there,
but
it.
A
B
C
A
A
I
don't
know
how
the
others
feel,
but
I
think
we
discussed
like
a
lot
of
things
and
we
very
often
go
into
into
a
rabbit
hole
of
finding
more
and
more
like
difficulties
or
or
challenges
like
we
did,
for
example,
for
the
destination
name,
so
I
was
wondering
if
we
should
maybe
define
like
a
plan
or
something
for
what
we
tackle
first,
for
example,
let's
because
I
think
we
still
don't
have
a
clear,
a
clear
path
for
for
like
a
single
message
scenario
so
maybe
like
that
could
be
most
of
people.
A
We
are
using
that
thing,
so
maybe
we
should
focus
on
having
a
good,
instrumentation
and
good
experience.
For
that
case,
I
think
we
already
tried,
but
then
we
also
reached
a
point
where
we
find
out,
but
what
about
this
case
for
the
other
for
batch,
for
example?
A
B
C
I
would,
I
would
really
support
it
and
we
can
stop
this
side
discussions
with
something
like
okay.
There
are
multiple
passes
and
for
like
for
single
scenario.
This
is
the
happy
way
we
recommend
to
do
this
and
we
prepend
it
with
should
not
must
right
so
where
let's
describe
the
happy
scenario,
and
if
we
will
discover
we
need
to
describe
more,
we
can
do
special
case
later,
but
we
don't
have
to
focus
on
it
initially.
A
Yeah-
and
we
also
probably
need
to
do
some
prototyping
as
well,
but
I
I
was
to
also
try
to
think
I
was
having
a
hard
time
how
we
would
do
this
because
I
not
familiar
with
any
instrumentation,
but
I
guess
if
there
is
one
that
we
could
pick
so
we
could,
for
example,
I
did
when
I
was
doing
like
a
long
time
ago.
A
I
was
doing
the
one
for
cloud
events,
so
I
picked
that
one
and
I
I
tweaked
it
make
it
do
what
I
wanted
and
then
I
sent
a
pr
to
them,
but
but
we
we
could
probably
pick
pick
one.
For
example,
let's
say
that
we
do
the
single
message
one,
and
we
pick
one
common
or
I
don't
know
popular
popular
messaging
system
framework
for
for
that
thing,
and
we
try
to
try
to
instrument
or
try
to
apply
our
conventions
and
see
what
kind
of
thing
we
get
out
of
it.
C
I
volunteered
to
help
I
have.
I
want
three
different
sdks
having
different
properties
and
things.
One
is
like
kafka,
another
like
rabbit
and
the
third
one
is
like.
I
don't
know
like
nothing
else.
I
volunteered
to
make
prototypes
of
any.
A
C
They
open
source,
but
then
conservation.
The
way
the
source
is
open
right,
not
in
a
way
that
it's
a
more
than
one
company
contributing.
I
guess,
if
we
need,
I
don't
know,
rabbit
or
kafka,
let's
see
if
we
can
find
someone
to
play
with
it.
So
maybe
we
can
get
help
from
our
java
friends
an
instrumentation
work
group
or
oh
sorry,
in
the
java,
instrumentation
sig
or
maybe
I
can
play
with
it,
but
maybe
somebody
else
will
volunteer
to
play
with
one
of
this.
A
Yeah,
I
can
also,
if
I
think
like,
if
we
have
a
plan
or
things
that
we
want
to
do,
I
guess
we
can
also
also
plan
like
internally.
I
can
also
bring
this
up
to
my
team
and
we
can
plan
it
and
I
can
work
on
it.
Yeah,
it's
just
just
a
matter
of
I
think,
prioritizing
and
defining
what
we
what
we
need
to
do.
B
So
if
I
have
a
general
question
here
regarding
like
this,
there
are
those
per
message
attributes
and
what
I'm
wondering
are
there
any
other
discussions
about
attributes
open
like
did
you
did
you
agree
on
the
on
the
remaining
attributes
or
is
there
is
there
more
to
is
there
apart
from
her
message
attributes?
Is
there
more
to
be
discussed
about
like
messaging
attributes
in
general,
just
found
them
about
the
I.
A
Think
we
did
discuss
some
of
them
and
we
did
knock
knocked
out
some
of
the
easy
ones
I
updated
their
tap
with
some
of
them
that
they
were
like
painting
the
requirement
level
and
things
like
that,
but
I
think
the
the
most
polemic
ones
are
still.
I
think,
the
last
time
that
we
updated.
A
I
updated
the
list
here,
but
then
I
stopped
putting
it
basically
much
about
it
anymore,
but
I
think
the
destination
is
the
big
one
that
we
didn't
finish
yet
the
url
all
the
all
those
we
didn't
finish
yet,
the
the
ones
with
the
beer
sock,
pier
with
with
all
the
or
the
protocol.
C
Yeah,
I
have
a
draft
for
request.
I
I
think
it's
a
bit
more
work
yeah,
so
we
discovered
that
the
links
cannot
be
expressed
with
the
current
pooling
and
I
think.
C
Let
me
see
if
yes,
yours
is
up
to
date.
I
will
keep
it
up
to
date
with
our
discussion.
A
A
What
what
what
ludmila
wanted
to
do
is
because
it's
kind
of
quite
hard
to
discuss
them
in
the
document
on
and
also
in
the
hotep,
so
we
we
wanted
to
do,
for
example,
to
put
them
already
in
the
ammo
format,
as
they
would
be
once
we
finish
and
then
produce
the
table
to
see
if
it
would
work
what
the
way
we
want
them,
and
then
we
could
also
easily
review
and
discuss
them
there
in
that
way.
Instead
of
doing
the
work
document
like.
C
And
I
think
the
destination
name
is
the
the
most
controversial
now
in
the
sense
that
we
don't
know
how
to
use
it.
If
it's
different,
so
the
happy
pass,
it's
the
same
right
and
if
it's
different,
we
should
probably
put
it
on
links
and
when
we
put
it
on
links,
I
think
the
last
thing
with
this
class
that
we
keep
the
name-
it's
still
messaging
destination
name,
but
it
just
goes
on
links
right.
C
Yeah
then
we
can
just
use
it
as
a
as
our
working
version
and
don't
spend
much
time
on
finding
problems
with
this
approach.
Yesterday,.
A
C
Yeah,
I
think
that
the
amazon
cues
they
they
have
like
the
region
and
the
q
name
right.
So
they
they
kind
of
have.
Oh,
they
have
a
destination,
but
they
don't
necessarily
have
the
net
peer
name
or
it's
not
descriptive
enough.
C
Message
is
put
into
the
queue,
then
how
it's
consumed
like
what
are
the
the
important
things
about
sns
and
sqs
to
know
the
destination,
and
we
usually
try
to
split
it.
In
two
parts,
the
one
is
like
the
broker
and
the
other
one
is
the
queue
name.
But
if
I
remember
correctly
in
case
of
ask
you
as
an
sns
that
it's
just
the
one
construct.
B
I
mean,
I
think
the
lambda
one
contains
sqs
and
ns
and
sns
parts
too.
A
So
what
somebody
wrote
instrumentation
based
on
and
they
had
a
problem
that
the
specification
doesn't
tell
how
context
is
propagated
and
things
like
that
and
the
person
had
to
pretty
much
figure
out
on
their
own.
A
Let's
it
here,
I
think
this
is
amazon.
Maybe
I
hear
sk
sqs.
A
But
this
guy
reached
out
so
I
saw
this
blog
post
and
I
reached
out
to
him
and
he
I
think
he
even
says
here
that
the
specification
doesn't
have.
A
C
So
maybe
we
can
come
up
with
some
proposal
or
actually
you
can
think
about
something,
and
then,
if
it's
possible
it
would
be
great
if
junior,
actually
someone
from
aws
can
confirm
it.
It
makes
sense.
A
Yeah,
because
we
there
is
this
few
destination
name
today,
but
we
don't
know
what
to
put
in
there.
I
think
in
the
old
time
in
the
original
odep,
I
think.
A
Yeah,
so
if
you,
if,
if
you
can
find
out
something
internally,
what
will
be
for
the
destination
url
and
the
destination
name?
How?
How
would
we
could
format
that
that
would
make
sense,
then
yeah?
It
would
be
great
because
I
think
the
url
is
also
one
that
we,
it
was
very
polemic,
didn't
reach
any
conclusion
right
that
we
discussed
like
for
a
couple
meetings
and
we
didn't
because
there
was
so
many
different
things,
different
ways
of
doing
it
or
different
things
that
we
could
put
in
there
and
also
in
destination.
C
But
I
guess
we
still
can
we
don't
have
to
solve
it
for
every
system
we
know
off,
but
we
we
can
describe
things
right
so
that
destination
name
is
something
that
identifies
specific
entity
queue
topic
subject
or
what.
However,
it's
called
right.
It
may
be
a
full
thing,
a
fully
qualified
namespace.
C
If
it's,
how
the
I
don't
know
the
broker
works
right.
It
can
be
just
the
past
that
identifies
it
within
the
broker.
C
So
if
it's
fully
identifies
the
thing
you
you,
we
still
want
net,
pure
name,
because
it's
the
common
network
layer
attribute
and
it's
used
beyond
messaging
specification.
C
So
you
either
fully
call
qualify
it
in
the
destination
name
plus
you
duplicate
it
in
the
network
name
or
you
just
identify
the
the
last
part
within
the
broker
and
then
broker
information
goes
into
networking
and
it
feels
like
anything,
can
be
described
using
these
two.
Then
there
is
a
tiny
redundancy
when
there
is
a
duplication,
but
it's
the
same
case
for
http,
where
we
use
the
stat
pure
name
attributes
just
for
the
metrics.
A
No,
I
mean,
but
we
have,
we
have
that
peer
name
and
then
we
have
url
and
we
have
something
else.
A
Three
so
there's
destination,
which
is
just
a
queue
name,
and
then
there
is
there's
the
url,
which
is
the
url
of
like
this.
This
arn
from
from
amazon,
maybe.
C
C
Url
right,
if
you
have
kafka
running
on,
I
don't
know
you
can
actually
use
it
and
start
running
locally
and
you
connect
using
unix
domain
socket.
There
is
no
url
right,
so
url,
it's
like
you,
might
have
it
and
also
it's
defined
as
a
connection
string
in
the
current
stack.
So
I
think
you
don't
even
need
it
because
it
doesn't
like.
If
some
system
wants
it,
they
can
have
it.
B
Yeah
I
mean
some
thoughts
from
my
side
here
is
that
with
we
have
destination
here
now
as
a
as
a
namespace
with
like
more
basically
things
underneath
it,
and
I
I
I
I
think
we
cannot
like
just
cover
everything
for
every
messaging
system.
In
our
specification,
I
think
there
needs
to
be
some
kind
of
thought
about
extensive,
like
extensibility
in
that
regard,
for
example,
I
just
imagine
that
yeah
we
can
have
destination.
B
I
think
what
we
are
just
a
bit
hung
up
here
is
whether
we
need
this
one
attribute
destination.name
and
we
need
to
be
the
destination,
be
uniquely
unique,
unique,
uniquely
identifiable,
but
just
this
one
attribute-
and
I
think
when
we
just
are
a
bit
more
relaxed
there
and
we
say:
okay,
there
might
be
several
there's
several
attributes
under
destination
that
help
to
uniquely
identify
the
destination,
and
that
might
be
system
specific,
is
to
the
system
to
define
that.
C
I
would
actually
say
that
we
need
an
attribute
that
uniquely
identifies
a
destination.
We
don't
need
to
specify
necessarily
what
it
is.
We
can
let
every
system
to
choose
then
like
when
you
draw
an
application
map
right.
You
know
how
many
nodes
you
want
to
show
right.
It's
the
basically
then
the
arrow
from
one
service
to
another,
but
then
it
identifies
the
queue
uniquely,
but
it
does
not
identify
it
fully.
Right.
You
have
can
have
more
information.
C
C
B
A
So
this
was
one
of
the
discussion
that
we
started
here
and
I
think
this
was
when
I
would
have
pointed
out
that
that
in
kafka
you
can
push
a
badge,
a
different
match
for
different
topics,
and
then
we
discussed.
I
remember
that
we
discussed
this
multiple
times
and
what
I
was
thinking
I
was
like.
Even
thinking
like,
like
you
just
said
like,
can
we
just
like
have
because
I
think
we
all
discuss
it
not
being
required
or
that
we
cannot
market
is
required,
but
I
was
also
thinking
like.
A
Could
we
just
like
step
back
and
and
and
say
it
just
give
some
idea
what
you
usually
put
in
the
destination
name
and
just
like
make
it
required
and,
and
just
say,
okay,
this?
Usually
you
put
this
information
here.
Whatever
you
have,
so
I
I
I
I'm
not
sure
like
I.
A
I
think
this
would
probably
work,
but
but
with
all
the
different
messages
that
maybe
they
could
augment
this
with
their
own
attributes
like
with
region
and
things
like
that,
but
but
with
the
thing
with
the
map
or
the
application
map
is
at
that
point
so
and
then
also
christian
also
had
another
point,
which
is
good
mentioning
that
if
we
don't
give
clear
guidance
like
for
example,
for
I
don't
know
sqs,
then
there
might
be
different
instrumentation
for
the
same
messages
and
they
might
do
things
differently.
A
So
it's
also
a
problem.
For
example,
I
think
that
today
the
destination
name-
they
they
put
it
as
a
topic
name
or
q,
name
right
in
the
current
conventions.
Sorry,
I
was
just
wondering
if
we
could
just
use
something
similar,
but.
B
I
mean
then,
in
that
regard
I
mean
an
alternative
solution
that
also
meets
ludmilla's
requirements
and
also
caters
to
what
the
christian
writes
here
would
be
that
we
just
in
this
general
specification,
we
just
say:
okay,
destination.name
needs
to
uniquely
identify
the
destination,
and
we
don't
say
much
more
and
we
just
defeat
them
up
to
each
individual
messaging
system
to
say
or
specify
what
exactly
should
go
in
and
we
like
on
from
the
general
side,
you
just
say:
okay,
it
needs
to
uniquely
identify
the
destination,
but
we
actually
cannot
see
more
because
then
what
goes
in
there
is
inherently
messaging
system
specific.
C
C
B
But
I
think
yeah
definitely
to
like
comment
my
proposal
a
bit
here.
If
we
have
this
requirement,
I
think
here
we
are,
we
need
to
use,
take
a
step
back
even
more
with
a
more
generic
and
just
say:
okay,
we
we
require
this
to
be
like
a
unique
like
an
identifier
that
uniquely
identifies
the
destination
in
the
end,
its
messaging
system
has
the
freedom
to
define
what
it
exactly
will
be,
and
I
think
there
should
be
a
messaging
system,
specific
definition
somewhere.
I
think
that's
what
christian
was
referring
to.
B
So
we
should
have
like
some
messaging
specific
definitions
there,
but
on
the
generic
side
on
what
you're
working
now,
we
just
put
the
requirement
out
there
and
we
maybe
have
some
kind
of
proposals
or
guidelines
on
how
this
could
be
done.
But
in
the
end,
like
each
specific
system
can
kind
of
give
give
give
their
specific
definition
of
what
goes
in
there.
A
I
think
that
I
think
that
makes
sense,
because
there
will
be
any
way,
sections
for
each
messaging
system
and
we
could
have
met
the
destination
name
at
the
top
and
just
give
this
general
guidance,
for
example,
in
the
table,
and
then
maybe
like
see
individual
messaging
systems
for
exactly
what
you
should
put
there.
Something
like
this,
maybe
maybe
we
could.
Maybe
we
could
go
this
way.
B
Yeah
because
I
mean
now,
I
think
the
attributes
that
we
have
required
are
messaging.system
and
dot
messaging.destination.name,
then,
in
the
when
our
changes
are
through,
and
I
think
that
if
every
individual
messaging
system,
then
that
kind
of
has
their
conventions,
there
should
at
least
clearly
specify
what
should
be
put
into
those
two
attributes
as
value.
So
I
think
that's
the
minimum
that
then
each
like
messaging
systems
should
clearly
should
clearly
should
clearly
layout.
C
C
No,
I'm
sorry
yeah
a
small
comment
that
for
event
degree
in
azure.
We
don't
have
a
cue
name
at
all,
so
we
have
just
a
broker
name.
So
if
I
need
to
write
a
spec,
I
would
say
that
either
we
duplicate
the
the
host
name
in
the
destination
name
or
the
alternative
could
be
that
the
host
name
will
go
into
netgear
name
anyway,
and
the
alternative
could
be
that
the
destination
name
is
a
conditionally
required
attribute.
That's
populated.
If
there
is
a
notion
like
that
at
all,
but
then
backhands.
C
And
like
if
we
make
it
conditionally
required
not
required
and
later
on,
we
discovered
that
we
absolutely
mean
destination
name
for
everything.
I
think
it's
a
gray
area,
but
I
think
we
can
change
it
to
required.
C
A
Okay,
all
right
so.
A
C
B
In
some
instances
putting
the
net
peer
name,
maybe
into
destination
name,
I
mean
at
least
in
my
feeling-
it's
not
even
that
bad
of
a
solution
to
just
like
duplicate
that.
I
actually
think
like
having
this
conditional
thing.
Where
is
the
okay?
Maybe
you
have
destination
name
and
if
not
then
fall
back
to
net
pure
name?
I
I
think
that
actually
makes
the
spec
quite
a
bit
more
complicated
and
also
makes
it
more
complicated
for
backhands
to
actually
then
make
sense
of
it
and
then
maybe
for
another
messaging
system.
B
C
C
A
Okay,
does
this
notes
make
sense
to
you
if
you're
looking
at
it,
but
do
we
do
we
want
to
have
any
plans
how
we
move
forward
the
destination
name?
Do
we
change
the
old
tab?
The
way
it
is
now
or
do
we
send
a
small
pr
like
we're
doing?
I
think
I
think,
for
this
one
might
be
just
in
the
hotep.
I
guess.
C
Maybe
I'll
I'll
try
to
update
my
yamaha
pr,
maybe
we
can
keep
it
somewhere
next
to
otab
and
because
the
yaml
file
is
easier
to
use
as
a
source
of
truth.
It
has
all
these
types
required
not
required
it's
like
nodes
and
stuff.
So
I
will
update
the
pr
with
this
discussion
and
if
we
are
happy
with
it,
we
can
just
merge
it
into
the
auto
and
that
that
will
be
auto-generated.
B
Yeah,
I
agree
I
mean
I
think
we
should
definitely
should
capture
it
somewhere
in
the
old
tap,
so
it
shouldn't
be
like
lost
and
buried
here.
So
I
think
the
old
tap
be
the
ammo
or
bit
some
text.
Written
should
be
the
source
of
truth,
because
these
notes
here
are
kind
of
hard,
yes,
but
better
better.
If
it's
in
yammer,
I
mean
even
better.
B
C
A
Yeah,
I
I
think
it
would
be.
It
makes
sense
to
have
it
on
the
message
so
like
per
message
as
well,
because
it's
my
messaging.
B
B
Okay,
so
I
think
that
maybe
some
discussion
we
can
then
have
next
week.
I
think
we
definitely
can
try
to
nail
down
the
semantic
meaning
of
this
field
and
for
requirements
level
and
where
we
put
it,
maybe
we
can
have
some
more
discussions
next
time
and
as
a
lot
of
homework.
I
I
think
something
also
comes
to
mind
here.
Maybe
we
can
also
think
about
that
in
the
relation
of
this
destination.name
to
the.
B
B
A
Just
one
nice
thing
before
we
go,
I
could
could
you
later
on
update
here
with
your
emails,
pr
url
or
something
like
that.
So
we
have.
A
No
problem,
yes,
we
can
also
continue
chatting
over
the
week
on
the
slack
channel.
If,
if
we
need
something
or
if
nobody,
somebody
needs
work
or
or
help
from
something.
B
And
and
thanks
so
trau
for
keeping
the
group
running.