►
From YouTube: 2022-08-04 meeting
Description
Instrumentation: Messaging
A
A
B
A
A
C
C
Well,
that's
that's
pretty
much
what
we'll
be
discussing
and
we
started
it
because
we
are
going
through
the
attributes
right
and
during
the
discussion
on
the
attributes,
the
the
destination
name.
I
think
it
was
lutemin
or
something
I
think
was
a
demeter.
She
found
out
that,
for
example,
in
kafka,
when
you
send
a
badge,
the
api
seems
to
allow
you
to
send
messages
for
different
destinations
on
the
same
badge.
C
And
then
we
ran
into
a
problem
or
or
we,
we
kind
of
went
into
this
discussion
of
what
to
do
with
message.
Specific
attributes,
for
example
like
in
this
case
the
only
way
or
what
will
be
discussed.
The
only
way
is
to
have
one
span
or
one
context
per
message.
Then
then
you
can
have
different
destinations,
it
doesn't
really
matter
right
and
there's
also
attributes
like
the
messaging
id.
The
message
id,
for
example
yeah.
C
C
A
C
B
C
C
C
C
C
C
C
No,
I
don't
want
to
go
for
it.
I
just
wanted
to
address
this
year
and
but
the
person
that
put
it-
it's,
not
you
I
guess
today,
so
we
can
just
skip
it.
Then
right
yeah,
the
next
thing
that
I
so
I
did
some
organization
in
the
agenda
and
I
looked
at
other
things,
so
I
kind
of
went
through
the
attributes
and
marked
them
the
the
status
that
we
have
and
also
went
through
the
current
old
tap,
and
there
was
some
comment
from
paolo.
C
C
So
that's
what
I
I
also
did
in
this
week.
So
I
looked
at
the
attributes
as
well
and,
as
I
was
saying
to
to
to
to
to
amir
and
the
others
before
you
joined
when
I
explained
that
we
were
talking
about
this
points
here
so
like
message,
specific
attributes
and
the
creation
context.
What
what
we
use
for
it
is.
Is
it
always
a
spam
or
is
it
something
else?
It
is
events
or
is
it
links
and
yeah
so
and
what?
C
I
wanted
to
ask
what
you
think
about
it
if
we
should
continue
since
this
is
fresh
on
our
minds
and
we
can
still
discuss
it,
I'm
also
fine
or
if
we
should
yeah
try
to
try
to
look
at
the
attributes
again
and
see
if
there's
any
any
ones
that
are
like
a
no-brainer
and
we
can
take
them
off
the
list
quickly
and
they're,
not
controversial
or
anything
like
that.
So
we
can
at
least
have
some
progress
in
other
things,
because
it
was
a
right
now.
B
B
C
Just
just
a
bit
yeah,
I
just
mentioned
that
we
were
talking
about
this
and
there
is
this
document
here
in
the
previous
video,
from
lu
from
la
demilla,
where
she
explained
like
the
idea
of
it
and
how
how
this
would
look
like
and
the
approaches.
So
having
always
having
a
span
like
we
have
now,
the
or
the
the
easiest
solution
is
always
having
a
span,
and
we
have
the
situation
here
right.
C
C
B
A
few
hours
ago,
but
in
terms
of
the
spanish
context,
I
I
just
sort
of
looked
into
the
spec
there
and
it
pretty
clearly
says
that
you
know
a
link
is
a
link
to
a
spam
and
it's
not
to
say
that
this
is
a
bad
idea.
But
if
we
were
to
go
down
this
path,
I
think
we'd
have
to
get
some
buy-in
from
a
broader
community.
Before
we
took
this.
D
B
My
other
thought
on
this
that,
as
I
thought
about
it
more
is
during
our
conversation
last
week
we
sort
of
like
we
sort
of
thought.
Okay,
the
back
ends
are
ultimately
going
to
have
to
create
something
like
some
object.
That
represents
this
thing
and
it
would
be
like
a
span
like
an
empty
span,
but
I
just
wonder
if,
once
you
do,
that
is
the
we're
trying
to
avoid
the
cost
of
a
span,
but
if
the
back
end
has
to
end
up
kind
of
creating
something
anyways,
have
we
saved
much.
D
B
I
I
do
think
there
is
the
other
option
of
not
having
a
zero
duration
span
right,
starting
the
span
when
you
decide
you
need
it
and
end
it
after
it's
been
sent
right,
whether
that's
a
single
message
or
part
of
a
batch,
whether
the
full
batch
has
been
sent
or
the
individual
message
has
been
sent
depending
on
the
messaging
system.
That
is
an
option,
doesn't
add
a
lot
of
value
over
the
duration
of
the
span
above
it.
B
B
D
And
regarding
your
second
comment,
I
don't
think
backhands
have
to
create.
I
just
mentioned
that
if
backhands
really
want
to
do
some
minimal
work,
they
can
fake
this
fan
and
create
one.
I
I
didn't
get
any
comments
yet
from
my
backhand
person
working
on
measure
visualizations,
but
I
don't
think
they
have
to
so.
I
think
this,
like
there
are
pros
of
this
option
that
there
is
a
very
minimal
information
we
sent.
We
save
on
costs
for
users,
on
storage
on
performance
and
I'm
trying
to
understand
it
feels
doing
you.
D
D
D
B
So
I
I
don't,
I
don't
think
the
spec
expressly
prohibits
zero
duration
span.
I
mean,
I
think
it
frowns
upon
it,
it
discourages
it,
but
I
don't
think
the
spec
would
have
to
change,
and
I
again
I
don't
know
if
it's
completely
invalid
to
have
to
set
the
duration
of
that
span.
Like
I
mean
it's
questionable
how
useful
it
is,
but
I
don't
think
it's
wrong
to
say
you
recognize
the
point
in
time
at
which
a
particular
message
needs
to
be
sent
and
the
measure
the
time
from
that
point
until
it
has
been
sent.
D
Right
so
you
would
create
wow
that
that
becomes
cool,
so
you
create
a
span
for
publish
you
attach
the
context
on
the
message
and
then
you
are
not
able
to
send
this
message
so
is:
does
it
mean
this
message?
Is
it
should
be
discarded
now
because
potentially
it
was
sent,
he
just
didn't
get
an
arc
right.
B
Yeah
I
mean
I
the
way
I
would
think
you'd
handle.
That
would
be
if
the
underlying
messaging
protocol
has
like
a
timeout
and
retransmits
or
something
like
that.
Those
would
be
like
events.
You
wouldn't
you'd,
keep
that
span
open
until
you
get
an
ack.
You
might
have
a
maximum
time
that
you
would
do
before
you
kind
of
consider
it
an
error,
like
you
probably
want
that
on
your
sdk
anyways
like
when
you
send
it.
B
D
Okay,
okay,
so
you're
sending
it
again,
okay
and
then
there
is
there
should
be
another
published,
spend
that
will
have
a
link
to
the
message
or
it
may
link
to
one
thing.
I
want
to
mention
that
when
spak
says
the
link
should
be
to
to
spam,
it's
a
strange
requirement,
because
if
you
received
something-
and
you
have
an
external
context-
you
you
you
can
know
you,
you
don't
know
if
this
context
had
a
span.
It's
the
first
thing.
D
D
An
assumption
it's,
I
don't
think
it's
correct
to
assume
that
it's
an
error.
I
can
have
one
thing:
sending
telemetry
to
one
place
and
another
thing:
it's
an
inflammatory
to
different
place.
It
can
have
different
sampling
settings
near
their
own
reasons.
Assuming
I
go
and
created
the
r
to
change
this
pack
to
have
a
span
context
to
assume
that
blink
can
be
a
two-spend
context.
What
would
be
your
arguments
against
it?.
B
I
mean,
if
you
can
do
that
great
I
mean
I
my
biggest
concern.
Is
that,
like
the
reason
I'm
trying
to
not
change
things
outside
of
messaging,
like
try
to
change
open
telemetry
is
you
know,
I
feel
like
progress
is
fairly
slow
and
if
we're
able
to
limit
our
scope
of
what
we
take
on
we'll
be
able
to
make
forward
progress
faster
and
to
the
extent
that
we
use
tools
that
are
already
available.
B
I
I
don't
see
a
lot
of
downside
to
the
per
message
span
and
in
the
batch
case,
where
you,
if
the
application
were
to
do
a
resend,
I
would
say
that
that
per
message
span
that
was
created
originally
right
when
on
the
first
send
that
could
be
set
in
the
message
at
that
point
in
time
as
the
creation
context
and
then
on
the
next
send.
The
message
already
has
a
creation
context,
and
so
you
just
link
to
it.
B
C
B
D
C
So
there
there's
gonna,
be
definitely
controversy
because
of
the
zero
duration,
I'm
sure,
but
what
is
easily
explainable?
Is
it
explainable
that
zero
duration
here
sometimes
is
true,
is
zero,
but
sometimes
it
actually
means,
like,
like
christian,
said
in
the
pr
that
you're
actually
measuring
the
the
time
where
you
need
to
get
some
data
to
create
the
message.
For
example,
that
could
be
the
creation
context.
C
D
So
what
I
suggest
is,
since
this
is
beyond
messaging
stuff
about
general,
open
telemetry
and
we
would
we
are
making
assumptions
what
would
be
harder
to
explain.
So
maybe
what
I
can
do,
I
can
come
to
the
tuesday
stack
meeting
and
it
presents
three
options
and
I
can
get
an
idea
of
what
people
think
about
it.
D
A
D
Let's
just
reduce
the
scope
and
maybe
say:
okay,
we
don't
specify
batching
at
all
at
this
time
or
we
actually.
The
span
context
is
a
minimal
thing,
because
you
can
instead
extend
it
and
not
spend
over
it
right.
Well,
you
cannot
undo
it
if
you
say
we
have
message
spent.
We
cannot
change
it
to
okay,
you
can
have
only
context,
sometimes
in
future
right.
So
it's
not
a
good
motivation
to
approach
design
decisions
from
what
would
be
faster
for
this
kind
of
spec,
even
though
I
also
pissed
off
about
the
speech.
B
Yeah
and
to
be
clear
I
mean
I
I
I
am
trying
to
make
sure
that
everything
we
propose
here
is
something
that
I'm
happy
with.
I
just
I
personally
don't
feel
that
the
span
per
message
is
a
terrible
option
and
if
I
did,
I
wouldn't
suggest
it
I
to
me
they're
just
kind
of
on
they're
both
on
the
fence.
I
don't
really
like
either
one
of
them
all
that
much
so
I
just
feel
like
I
don't
see
a
lot
of
downside
to
the
per
message
span.
B
C
B
C
Was
the
so
when
we
started
amir
was
I
was
chat
with
amir
then
I
think
there
is
another
case
which
we
didn't
represent.
The
thing
here,
which
is
what
amir
remain
remind
me
of,
that
we
have
one
one
span
for
the
whole
batch
instead
of
yeah.
So
I
think
we
did
discuss
this,
but
I
I
I
don't
remember
seeing
any
comments
or
any
thing
in
written,
so
maybe
we
didn't
write
it,
but
did
we
entertain
this
idea
more
or
maybe
we
should
think
about
it.
C
Yeah
so
like
one
only
one
span
for
for
for
the
entire
batch
and
the
same
span
is
used
in
other
the
messages.
But
then
we
have
the
problem
of
of
message
messaging,
individual
attributes,
but
we
have
this
option
right
like
if
you
don't
want
to
have
once
been
pretty
much
because
it's
expensive
or
something,
then
we
only
offer
this
option.
A
I
think
we
discussed
it
quite
a
lot
when
we
talked
about
producer
spence
and
if
caught
me
from
one,
but
I
think
we
had
like
three
options
about
how
to
represent
producer
spence
in
a
patch,
and
we
understand
that
none
of
them
is
really
good.
So
we
decided
that
we
allow
either
to
create
one
spend
per
message
if
there's
a
want
to
or
if,
if
it's
too
expensive,
like
you
said
john,
then
you
can
decide
not
to
do
it,
but
then
it
loses
the
per
message:
breakdown
right.
D
A
So
what
we
agreed
on,
if
I
remember
correctly,
is
that
if
it's
too
expensive,
then
user
can
opt
out
of
this
verbose
mode
and
just
create
a
single
span
for
the
entire
patch,
but
it
means
that
you
also
lose
the
breakdown
of
their
message
like
knowing
which
messages
are
involved.
What
attributes
they
hold.
D
Yeah,
so
why
we
started
talking
about
it
is
because
we
started
to
discuss
per
message
attributes
and
we
realized
that
given
destination
name
could
be
from
per
message
and
then
we
started
to
think.
Where
will
you
put
this
attributes
and
there
are
two
options
one
is
on
on
per
message
span
if
we
have
it,
but
I
think
we
should
not
do
this
because
of
two
reasons.
The
first
reason
is,
I
can
forward
message
so
it
can
go
through
multiple
hops
and
then
I
would.
I
cannot
create
the
message
then
on
each
home.
D
A
D
D
D
A
C
D
C
Really
like
it,
so
that's
it
it's
not!
That
is
written.
That
is
not
allowed,
but
it's
just
something
that
we
will
definitely
once
we
have
this
to
be
reviewed.
Definitely
people
will
will
talk
about
this
and
and
will
get
a
blocker
or
something
hit
a
blocker
or
something
okay.
So
I
I
noted
this
down
that
we
have
the
intention
to
present
this
idea
is:
is
there
any
any
anyone
volunteers
to
to
to
do
this?
I.
C
C
Okay,
what
is
the
other
thing
that
the
other
thing
that
I
want
to?
So
we
okay,
so
we
we
have
this
this
thing.
I
think
it's
a
good
idea
that
we
get
some
gauge
some
some
the
intentions
there,
but
I
guess
there's
no
much.
We
can
go
forward
right
because
there
is
pros
and
cons
for
both
things
and
and
not
pretty
sure
right.
So
maybe
I
also
document
the
thing
about
the
single
span
for
the
whole
batch.
C
B
C
That's
the
hard
part
right
that
we
we
take
it
off,
but
we
also
have
to
keep
still
thinking
about
it
because
yeah,
whatever
we
come
come
up
with,
we
need
to
make
sure
that
this
you
know
and
then
maybe
make
sense
to
not
to
do
it
anyway,
because
if
you
have
to
keep
thinking
about
it
yeah,
but
I
think
it's
an
option.
Yes,
we
could
do
that
as
well.
C
But
without
this
discussion
I
was
wondering,
if
does
it
still
make
sense
to
do
it?
But
I
think
with
your
responses
and
which
we
discussed
now,
maybe
it
does
even
if
it
if
it
doesn't
get
merged,
but
at
least
there
will
be
something
there.
I
guess
and
then
maybe
there
is
even
a
way
to
use
this
as
a
point
to
discuss
about
this.
Actually
this
exact
this
exact
thing
about
what
what
what
is
the
creation
cons,
because
I
think
in
the
tab.
C
C
C
I
was
thinking,
maybe,
if
there's
any
easy
attributes
that
we
can
go,
go
through
and
get
them
done
or
have
a
plan
of
what
to
do
with
them,
because
I
thought
that
there's
a
lot
of
comments
from
you
to
me
as
well
about
the
requirement
levels
and
so
on
some
of
them.
I
think
I
addressed
already
this
through
this
week,
but
there
is
yeah
there
was
this
broker
that
we
kept,
as
as
I
think
it
was
messages
we
decided
to
keep
it
messaging
system,
but
the
requirement
I
was
too
wrong.
C
C
A
C
D
C
C
C
But
I
I
actually
looked
at
the
beginning,
but
there
was
it
was
a
lot
of
stuff
to
do.
It
was
kind
of
a
draft
more
or
less.
It
was
a
lot
of
errors
and
and
inconsistency,
and
things
like
this,
so
I
thought
it
was
like
just
a
whip
for
now.
I'm
not
gonna
all
right.
So
I
think
you,
you
had
a
lot
of
comments
as
well
on
it.
So
it's
like
yeah
probably
still
work
on
this
so
but
yeah.
D
Sure
but
and
yes,
we,
we
should
not
hold
them
right,
it's
their
specified,
pools
our
specific
attributes
and
we
don't
know
when
our
spike
will
run.
So
I
mean
it's
just
probably
we
can
let
it
be
merged
and
then
we
can
just
make
sure
that
people
know
that
it's
an
experimental
spec
and
it's
likely
to
change.
B
Yeah,
I
think
that's
the
main
piece
feedback
I'd
have
is
make
sure
they're
aware
it's
on
top
of
an
experimental
spec
and
that
their
spec
should
be
an
experimental
and
outside
of
that.
Let
them
and
then
you
know,
let
them
know
we're
changing
stuff,
but
other
than
that.
I
see
no
reason
to
to
hold
them.
C
Yeah
the
problem,
the
problem
that
I
see
is
that,
for
example,
if
we
allow
this
to
merge
and
and
then
we
change
everything
and
then
who
is
the
owner
of
this
right,
because
we
can't
be
the
owner
of
old
semantic
conventions
for
all
the
things
right
I
mean
we
should
be
the
reviewers,
but
if
they
things
needs
to
be
touched,
then
we
have
to
probably
take
care
of
take
care
of
this
right.
So
this
is
a
bit
where
I'm
I'm
not
afraid,
but
I'm
a
bit
hesitant.
C
D
D
D
C
I
can
write
if,
if,
if
everybody
agrees,
I
can
write
that
that
this
is
going
to
be
on
top
of
experimental,
it
might
be
it
might,
it
might
change,
because
our
conventions
might
change
a
lot
yeah.
But
apart
from
this,
I
guess
we
can
review
and
and
and
maybe
a
proof
and
and
see
if
the
others
also
prove
it,
but
it
seems
that
it's
enacted
the
person
didn't
come
back
so
I'll.
I
think
I'll
write
this
and
see
by
the
way.
C
C
I
don't
know
if
you
know
this
if
you
ever
saw,
but
we
were
added
to
this
group
and
a
while
ago,
and
and
all
of
us
are
now
part
of
this,
this
instrument,
instrumentation
group
and
our
group
now
has
has
a
proof
of
power
so
before
it
didn't
work,
because
we
didn't
have
permission,
I
think
on
write
permissions
to
the
repository,
but
I,
as
I
I
saw
this
and
I
asked
armin
and
they
fixed
it.
Also.
C
D
C
C
This
group
here
yeah
and
now
we
have.
We
have
approval
rights
in
the
in
this
spec
repo
and
they
they
they
they.
When
it's
semitic
convention
area
this.
I
think
this
group,
this
team.
I
think
it's
called
it's
already
added
as
every
viewer.
So
yeah
you
might
get
a
lot
of
emails
if
you
didn't
unmute
the
emails
or
something
from
github.
C
C
C
All
right
so
should
we
take
a
look
at
the
attributes
that
we
have
for
now
or
yeah?
Let's
do
it,
let's
do
it.
We
have
15
minutes.
I
think
we
can
take
a
look.
So
destination
is
the
is
the
is
the
problematic
one
that
we
keep
discussing.
So,
let's
see,
if
there's
any
other,
did
we
settle
on
the
template,
though
I
think
this
one.
D
B
An
async
api
async
api
is
one
okay,
async
api.
I
think
I
mentioned
it.
It
has
channel
parameters
which
is
describing
the
the
destination
and
and-
and
I
still
and
I've
made
a
case
as
well-
that
I
think,
regardless
of
whether
the
system
has
a
native
concept
of
it
applications
if
they
can
inject
it,
it's
very
valuable
to
have
information
to
have
right,
it's
an
application
layer
concept
and
if
applications
can
inject
it,
it's
an
optional
thing.
B
B
A
C
Yeah,
I
I
think
the
last
thing
that
there
was
a
discussion.
I
think
the
last
thing
was
this
comment
from
johannes
that,
because
it
was
discussed
at
the
discussion
of
system
that
supports
high
cardinality
and
the
topics
then
cannot
be
in
the
spain
names
and
things
like
this
so
yeah
this.
This
might
be
something
that
we
can.
I
I
was
reading
and
I
was
thinking
okay.
Maybe
we
can
always
have
this
also.
C
I
also
was
having
the
same
same
thought
like
we
can
all
we
can
also
always
have
this,
of
course,
not
can
be
optional,
even
not
not
even
recommended,
I
think,
or
even
recommended.
I
don't
know,
but
definitely
not
require,
of
course,
because
it's
not
available
but
yeah,
but
I
I
think
we
still
didn't
decide
actually
on
the
name.
I
don't
think
template
is
the
one
that
we.
B
C
C
C
And
I
don't
think
we
had
any
that
is
like
true
or
false,
so
far,
yeah,
because
with
this
you
have
this
situation
right
so
like
like
johanna,
said
here.
So
if
it's,
if
it's
a
boolean
set,
then
like
what
what
is
the
recommended
or
or
how
do
people
say?
Do
we
always
set
this
and
said
always
to
to
false
or
only
set
it?
They
only
put
there.
When
is
true
things
like
this,
but.
B
D
C
A
C
D
C
C
C
B
C
A
C
D
Yeah-
and
I
don't
think
we
came
up
to
the
conclusion,
because
where
we
stopped
was
this
her,
the
topic
is
her
message
potentially
right
and
then
the
problem
how
we
ended
up
there.
We
tried
to
understand
how
what
uniquely
identifies
the
topic
right
and
that's
the
combination
of
a
host
or
some
resource,
maybe
an
aws
or
something
that
identifies
the
the
the
multi-tenant
host
right
and
then
the
single
tenant
topic,
and
I
think
a
url
was
an
attempt
to
define
the
address.
Maybe,
but
it
doesn't
seem
like.
D
D
Okay,
okay,
so
like
there
is
a
general
spec
that
suggests
how
to
represent
the
net
pure
name
and
it's
useful
to
follow
general
stuff
right
and
then
there
is
a
topic
name,
but
there
are
also
topic
names
per
message
potentially
and
then
also
topic
name
can
be
a
complicated
structure.
There
is
more,
there
is
sometimes
namespace
and
tenant
id,
and
things
like
that.
So
the
question
is:
what
do
we
actually
do?
C
Yeah,
that's
what
I
was
wondering
it's,
it's
kind
of
amazing!
Isn't
it
that
it
says
connection
string
and
is
it
it's
not
really
safe
to
put
a
connection
string
there
right
because
yeah,
I
think
in
azure
you
have
all
the
information
there
right.
The
some
sensitive
information
in
the
connection
string
right.
D
D
C
D
At
least
it
identifies
something
fully,
but
it's
a
question
whether
we
can
have
a
url
like
that
for
everything,
and
at
least
in
case
of
azure.
This
would
be
an
artificially
created
thing
constructed
from
two
parts:
the
the
host
name
and
the
topic
name
or
q
name
and
in
case
of
other
systems.
It
could
be
that
they
don't
have
a
url
like
content,
but
we
can
ask
to
create
an
artificial
thing
if
we
believe
it
makes
sense.
I
left
a
comment
with
different
options
somewhere,
I'm.
C
C
He
I
think
what
is
this
yeah,
so
he
he
thinks
that
he's
not.
He
doesn't
like
that
that
the
attitudes
are
under
this
new
net.
For
example,
like
we
have
here
now
netapp
protocol
version.
He
he's
opposed
because
he
says
I
think
he
says
you
that
it's
it's
a
messaging
protocol
and
why
is
it
on
the
net
and
adding
messaging
dot?
C
D
Yeah,
johannes
edited
it,
but
the
reasons
are
that
this
is
a
generic
attribute,
that's
all
for
all
open
telemetry,
and
if
we
define
messaging
protocol
we
would
just
have
a
an
intersection
with
that
one.
You
can
have
messaging
cover
http.
Why
not
so,
then,
if
we
just
include
messaging
specific
messaging
protocols
here,
it
will
be
just
repeat
that
the
general
spec.
C
Yeah,
so
that's
what
I
that's
what
I
read
so
I
read
so
christian
pointed
out
that
this
is
why,
right
so
because
it's
it's
not
network
stuff
anymore,
it's
it's
it
that
the
net
doesn't
doesn't
mean
it
is
a
network,
and
then
I
followed
the
pr
your
http.
I
looked
at
them
a
bit
and
it
makes
sense
to
me
that
this,
because
it's
it's
to
be
shared
more
or
less
right,
so
so
the
call
so
the
concepts
can
be
shared
and
it
it
was
kind
of
clear
to
me.
C
I
understood
it,
but
it
doesn't
seem
that
he
seemed
that
he
looked
at
the
pr
and
still
still
think
it's
a
good
idea.
So
I
do
know
how
to
reply
that
this
is
this
is
it
is
what
it
is
now
and
and
we're
not
going
to
change
it
and
why?
But
I
can
try
to
explain
that
it's
because
of
this
point
I
just
share
it
yeah.
D
D
Name,
but
there
is
also
a
host
information
and
the
destination
name.
My
understanding
this
is
a
topic
name
or
q,
name
yeah,
so
for
aws
what
they
have
to
identify
resources,
it's
different
things.
So
it's
it's
an
example
for
lambda,
but
at
least
that's
what
dws
folks
reviewed
and
more
or
less
happy
with.
So
they
have
some
information
about
account
id
and
the
the
host.
C
D
D
A
D
And
the
url
is
part
of
this
problem
and
also
what
goes
to
destination
name
because,
for
example,
for
pulsar
there
is
this
big
construction
that
is
passed
as
a
string,
but
internally
this
is
called
namespace.
This
is
called
10
and
a
d,
and
this
is
called
a
topic
name.
So
I
think
this
all
things
should
go
to
destination
name.
C
B
Ahead
yeah,
I
was
gonna
say
I
agree
with
that
too,
that
like
leave
it
a
little
bit
open,
let
each
system
define
what
makes
sense
you
kind
of
have
to
indicate
what
the
intent
is.
You're,
trying
to
uniquely
identify
a
destination
where
the
message
is
going
and,
and
also
I'd
say
like
if
you
know
for
a
particular
system,
it's
not
possible
to
like
it's
not
practical
to
identify,
add
other
attributes
for
that
are
messaging.
B
C
I
think
the
the
problem
is
that,
because
today
it's
required
in
the
conventions,
and
then
we
start
discussing
that
if
we
want
to
keep
it
required,
then
we
need
to
have
a
clear
way
of
of
what
to
put
there,
but
maybe
we
can
still
have
it
required,
but
just
say:
okay,
you
need
to
put
something
here
that
that
that
that
identifies
the
the
destination-
and
maybe
we
can
give
some
examples
like
in
some
popular
system
like
here
in
this
system.
You
can
use
this.
C
It
is
this,
but
but
in
the
end
we
we
have
to
leave
it
like
to
them
right
and
having
it
require.
I
think
like
what
we
see,
I
think,
is
that
there
is
always
a
way
to
put
something
there
that
works
for
a
system,
but
it's
not
the
same
for
all
them,
but
I
think
there's,
there's
always
a
way
right
to
put
to
put
there.
D
C
D
The
key
part
is
that
we
want
to
say
that
it
should
be
the
full,
unique
identifier
within
a
broker
right
and
that's
good
enough,
and
then,
if
specific
systems
once
want
to
expose
them
separately,
they
should
just
create
in
their
own
specific
attributes,
with
their
own
concepts
right.
I
think
this
is
good
enough
for
any
kind
of
attribute.