►
From YouTube: 2022-11-03 meeting
Description
Instrumentation: Messaging
A
B
B
Okay,
so
I
put
well.
That
was
two
things
up
on
the
trend
of
the
day.
The
first
is
continuing
the
discussion
on
the
on
loot,
Wheeler's
PR,
for
attribute
changes,
and
so
there's
still
some
open
comments.
Maybe
we
can
go
over
those
today,
maybe
close
on
some
of
them
and
then
see
how
we
can
can
let's
proceed
with
that.
Pr
and
I
also
put
two
issues
here
that
maybe
we
should
quickly
talk
about,
because
there
has
been
some
requests
that
the
messaging
group
look
over.
B
Those
one
is
related
to
adding
additional
attributes
to
the
rapidmq
part
of
semantic
conventions,
and
one
is
for
rocket
mq
parts
I
mean
the
remedy.
Mq
part
is
an
interesting
one,
because
the
question
here
is
whether
a
better
this
adding
those
generic
message
headers
whether
this
should
be
like
a
like
in
the
should
be
part
of
the
trainer
or
messaging
semantic
conventions,
and
not
webmq
specific,
so
yeah
I.
Think
a
good
thing
for
us
to
discuss
is
we
are
into
all
the
attribute
stuff
anyway,.
D
D
I
think
this
will
have
the
same
question
and
I
I
wanted
to
give
a
quick
update
on
what
we
discussed
last
time,
there's
Amir
and
Wayne.
So
basically
the
general
thing
we
discussed
that
we
need
to
have
a
some
convention
for
some
structure
in
attribute
names
right.
So
we
expect
to
see
the
messaging
dot
system
dot
the
namespaces
and
based
on
this
backance
by
knowing
those
namespaces,
they
can
apply
some
logic,
but
even
if
they
don't
know
some
namespace,
they
can
kind
of
group
by
specific
segment.
D
D
We
cannot
guarantee
that
there
will
be
just
one
system
and
attributes
right
because
it
can
be
GMS
and
amqp
and
private
mq
potentially
on
the
same,
and
we
don't
want
to
block
it
so
I
think
the
conclusion
we
came
to
was
that,
yes,
we
need
the
structure,
but
we
cannot
require
system
messaging.system
to
match
this,
the
namespace
specific
to
the
system,
but
I
guess
we
can
to
write
to
come
up
with
some
guidance
like
merging
this
to
discussions,
the
pr
and
the
issues
they
have.
D
B
Yes,
I
I'm
sorry
last
week,
I
couldn't
participate
so
I
I,
just
yeah
yesterday,
I
booked
my
thoughts,
I
just
saw
this
here
and
I.
Put
my
thoughts
yesterday.
Hearing
this
comment
and
like
I
can
quickly
summarize
here
regarding
the
just
taking
this
example
with
stream
as
mqb
and
rabbitmq
I.
Think
from
in
my
opinion,
mqp
will
not
end
up
in
messaging
system,
but
a
bit
more
end
up
in
that
app.protocol.name
I.
E
D
This
is
what
Dwayne
had
a
lot
of
considerations
onto
so
basically
you
can
use
plain.
It's
like
his
point
is
MTP
is
so
messaging
specific
that,
and
you
can
also
talk
the
messaging
system
using
Justin
and
PP
Library,
so
he
was.
He
fell
through
a
strong
that
just
setting
it
in
the
protocol.
Yes
well,
but
it's
just.
It
can
be
that
some
we
have
a
messaging
semantics,
but
have
just
ampp
as
a
system
good.
B
Morning,
yeah
I
mean
I
and
my
the
second
point
I
added
here
is
was
about
this
is
about
this
case.
When
mqb
is
used
without
I
mean
it's,
it
said
that
we
don't
have
to
end
here
today.
So
maybe
he
respond
to
this
comment.
I
will
ping
him
to
get
his
opinion
on
that,
and
also
don't
want
to
kind
of
skew
any
discussions
that
happened
last
time,
but
just
to
do
layout.
B
My
take
here
my
take
is
that
for
mqp
I
I
see
that
there
will
be
like
a
separate
semantic
conventions
for
mqp
at
some
point
and
as
the
mqb
is
kind
of
this
I
I
think
I
see
it
as
kind
of
this
transport
layer
instrumentation
the
mqb
instrumentation.
It
might
be
something
that
you
can
then
activate
like
in
addition
to
the
regularly
like
messaging
instrumentation,
so
you
will
actually
get
dedicated
spans
for
those
mqb
operations
that
are
kind
of
children,
maybe
of
the
publish
or
receive
operations.
B
So
if
you
that's
just
kind
of
a
vision
that
I
have
in
my
head,
so
if
you
don't
need
these
transport
instrumentation,
you
just
see
in
that
protocol
name.
Okay
and
QB
was
used,
and
if
you
want
to
have
like
a
view
into
this
mqb
operation
stem
cells
or,
if
you're,
only
using
mqp,
then
you
will
just
get
spans
according
to
this
mqp
semantic
conventions.
That
kind
of
cover
the
transport
layer.
D
D
If
you
have
them
right
and
it
would
be
nice
to
be
able
to
Define
at
least
message
attributes
was
this
properties
right
and
then,
if
we
put,
if
you
don't
put
altp
there,
we
would
have
to
put
a
specific
system
and
then
it's
just
a
very
hard
requirement
to
say
that
you
cannot
hear
say
if
you,
you
have
to
use
your
messaging
system.
B
I
think
that
makes
sense
to
me.
I
will
I
will
think
about
it
a
bit
further.
Let's
see
what
you
discussed
it
last
week,
so
I
kind
of
trust,
the
outcome
of
your
discussions
of
when
you
said.
Okay,
we
have
to
mix
this
on
single
spans.
B
A
I
I
have
a
question:
do
you
think
this
issue
is
a
blocker
for
the
pr
to
to
get
merged?
Is
it
like
something
we
have
to
decide
on
to
to
merge
this
PR,
or
maybe
we
can
they're
like
like
walk
to
to
merge
only
the
breaking
change
their
names
and
then
do
it
in
a
follow-up,
yeah.
D
I
think
I
have
a
sentence
in
this
pillar
that
says
that
the
the
system
messaging.s
system
must
match
the
namespace
in
the
actually.
The
names
I
can
relax
the
sentence
and
then
it
won't.
We
can
just
discuss
it
separately
and
I
think
it
would
be
nice
since
I
already
have
something
about
the
naming.
D
Maybe
we
can
each
of
us
who
is
interested
review
this
PR
and
see
if
what
they
have
from
the
naming
is
enough.
I
think
America
had
the
most
opinions
on
this,
so
maybe
you
can
take
a
look
and
see
if
you
like,
what's
written
there
and
then
I
guess
yeah.
We
can
separate
this
to
this
question.
A
D
B
Okay,
just
to
clarify
for
me,
you
look
with
an
army.
What
we're
talking
about
here
is
this
feature
more
or
less
that
this
this
here,
basically
that
this
system
here
should
exactly
match.
Messaging.System.
Is
this
the
yeah
this
requirement
or
sentence
here
you're
referring.
A
To
here,
yeah
and
and
I
want
to
suggest
to
do
it
more
generally
and
not
specific
to
messaging.
A
Yeah
but
but
I
think,
if
I'm
not
mistaken,
like
what
we
discussed
last
week.
Is
that
like
what
to
put
like,
we
know
that
we
want
messaging
system,
but
we
have
these
other
entities
and
we're
not
sure
what
should
go
well
like
foods
like
if
there's
a
couple
of
them
like
what
attributes
should
all
the
other
ones
and
and
then,
if
we
want
like
a
attributes
that
are
specific
to
something
which
is
not
system,
how?
How
do
we
do
it,
but
I
think.
C
C
I
I
agree:
it's
not
necessarily
related
as
long
as
the
pr
whatever
we
submit
allows
for
something
other
than
like
another
namespace
in
messaging.
Besides
the
one
identified
in
system
but
I
think
anything.
It
does
apply
to
the
system,
insisting
that
it
uses
that
messaging.system
namespace
makes
sense
to
me.
But
if
it's
flexible
enough
to
allow
messaging.jms
when
the
system
is
ampp,
for
example,
I
think
would
be
ideal.
B
So
until
trustum
is
on
the
results
of
your
last
week's
discussion,
so
basically
just
making
yourself
experiment
so
I'm
using
I,
don't
know
rabbitmq
with
mqp.
So
then
messaging
system
would
say:
rabbitmq
net
app
protocol,
name
might
say
amqp
protocol
version,
let's
say
0.9
whatever,
and
you
might
have
mqb
specific
attributes
on
this
band
too,
and
if
you
just
use
amqp
without
anything
underneath
the
messaging
system
itself
might
be
mqp
and
you
will
also
have
those
mqp
specific
attributes.
B
A
Yeah,
this
is
where
it's
get
confusing,
because
mqp
is
not
really
a
system
right
and
then
we
will
not
have
consistency.
One
time
it
will
be
the
messaging
system
and
others
I.
C
I
I,
I
I'm,
not
sure,
I,
understand
the
statement
that
MPP
is
not
a
messaging
system
like
rabbit
empty,
confuses
things
because
rabbitmq
used
some
pre,
you
know
0.9,
which
is
not
really
ampp,
so
I
think
I
think
we
have
to
kind
of
take
rabbitmq.
But
let's
talk
about
amqp
1.0,
which
is
what
amqp
is
and
I
think
it
at
its
layer.
Its
intent
is
to
provide
all
of
the
messaging
Concepts.
C
We
talk
about
here
and
so
I
think
it
makes
sense
for
to
to
label
like
the
the
message
ID,
the
amp
message,
ID
and
everything
else,
all
the
destination
source,
everything
we're
talking
about
at
the
amtp
layer
and
saying
that
it
is
a
messaging
system.
A
I
think
it
should
follow
a
messaging
semantics
on
data
totally
agree,
but
I
think
the
name
system
is
a
bit
confusing
in
this
context,
and
we
have
it
also
in
databases.
So,
if
you're
connecting
to
a
postgres
but
you're
doing
it
with
an
orm,
then
you're
not
expecting
to
select
the
orm
name
in
the
database
system
like
you're,
expecting
to
see
postgres
because
I
don't
know
when
you
say
system.
This
is
like.
What's
the
expectation,
at
least
that
makes
sense
to
me,
but
but
we
can
have
this
discussion
in
another
PL.
B
I
I
think
maybe
we
should
just
keep
this
maybe
requirement
for
relaxed
here,
and
we
can
recreate
like
item
on
our
task
board.
B
What
I
can
do
I
have
those
examples
from
like
quite
some
time
ago,
where
I
had
like
this
messaging
spans
on
top
of
mqb
product
on
the
of
the
mqb
protocol.
So
they
were
like
the
messaging
systems,
bands
and
the
mqp
spans.
Underneath
I
can
dig
that
out
again
and
then
then
we
get
to
discuss
that.
Then
we
can
or
I
can
I
can
dig
it
out
until
next
time
and
we
can
look
at
that
and
then
maybe
see
better
like
this
example
helps
us
to
figure
out.
F
C
I
think
the
concern
with
that
is
that
adding
support
for
a
new
system
affects
the
core
spec
because,
as
to
add
the
enumeration
value,
but
I
I
think
it
should
be
sort
of.
We
should
allow
new
specs
that
follow
like
new
systems
effectively
that
follow
messaging
semantics
to
Define
their
own
and
be
added
without
affecting
the
Core
specs.
B
Okay
I
remember:
we
had
this
discussion
with
Clements
actually
long
ago
and
and
his
opinion
was
that
his
messaging
system-
it
should
definitely
not
be
basically
the
values,
allowed
values
for
this
messaging
system.
It
should
not
be
part
of
the
spec,
because
that
will
kind
of
will
make
it
very
hard
to
kind
of
add
new
messaging
systems,
because
the
new
book
that
actually
need
to
kind
of
amend
the
specification
and
get
that
merged.
B
I
mean
the
the
point
is
that
when
you,
when
you,
when
you
want
to
use
a
system
that
is
covered
by
this
semantic
conventions,
just
keep
a
moment
when
you,
when
you
want
to
use
Kafka
for
example,
then
then
this
value
is
defined
so
for
certain
set
of
messaging
systems.
B
Because
I
think
for
Kafka
we
Define
this
messaging
system
that
it
must
be
Kafka
at
some
point
if
I'm
not
mistaken,
and
if
we
don't
do
that,
we
should
do
that.
So
for
those
no
messaging
systems
that
are
treated
by
this
semantic
conventions,
where
we
have
a
specific
eventually
for
Kafka
rapidmq
rocket
mq
there,
the
value
for
this
system
is
defined.
B
C
I
I
do
think
it'd
be
better
when
we
get
to
the
stable
specification.
If
this
specification
doesn't
Define
any
systems
at
all
and
like
just
because,
if
kafka's
evolving
and
adding
new
features
and
wants
to
change,
you
know,
what's
in
the
Kafka
namespace
I
I,
don't
feel
it's
right
that
it
should
be
modifying
this
specification.
I
feel
like
it
should
be
a
separate
specification
on
its
own.
B
Yes,
I
think
that
is
part
of
this
effort
that
we
now
we
have
the
Kafka
specific
rabbit
and
Q
specific
and
Rocket
mq
specific
stuff
in
the
same
document.
I
think
it's
definitely
that's.
Actually
something
I
wanted
to
look
into
to
split
this
out
into
separate
documents,
so
we
have
one
document
for
the
generic
messaging
semantic
conventions
and
then
we
have
other
documents
separate
for
the
specific
semantic
formations.
So
we
keep
those
kind
of
values
for
system
completely
out
of
of
the
general
document.
D
B
D
D
It
tell
us
a
Ray
attributes,
so
we
cannot
entertain
this
idea,
but
they
haven't
seen
any
semantic
convention.
Yet
that
uses
it
and
we
don't
know
the
consequences.
We
don't
know
how
hard
it
would
be
for
backend.
So
thank
you.
I
think
we
can
entertain
it,
but
I'm
not
sure
if
we
can
do
anything
yeah
working
with
it.
B
I
I
think
it
is
here
for
that's
how
it's
done
for
databases
I,
think
that's
as
close
as
you
can
come
to
an
enumeration.
What
basically
says
yeah,
if
it
says
DB
system
has
a
following
well-known
values,
and
if
one
of
them
applies,
then
this
must
be
used,
and
otherwise
you
may
use
a
custom
value.
So.
D
F
On
the
spec
that
the
reasons
on
implementations
I
think
it's
it's
hard
to
go
away
from
an
enumeration,
because
otherwise
it's
going
to
be
very,
very
hard.
But
well
the
system.
The
system
is
actually
I,
think
a
special
case
because
it
it's
so
vast
and
it
can
grow
or
in
an
arbitrary
way,
but
things
that,
like
the
kind
and
other
attributes
that
are
clearly
Limited
in
scope
and
are
not
expected
to
go
to
grow
that
much
that
they
could
be
set
up
as
an
enumeration
from
Star.
Not
just
a
free
stream.
D
So
we
we
do
like
in
the
yaml
file
for
a
messaging
and
database,
it's
specified
as
an
enum,
and
you
can
set
the
flag
saying:
okay,
our
custom
balanced
a
lot,
so
it's
supported
from
the
tooling.
We
can
Define
it
as
an
enum
and
we
should
obviously
allow
custom
values
and
I
think
this
is
separate
conversation.
Where
do
we
need
to
keep
the
all
the
specifications?
Let's
focus
on
how
much
we
want
to
Define
span
naming
structure
for
this
extensions
to
follow.
F
F
But
I
think
I
think
like
it
is
it's
fine
for
first
iteration
you
can
discuss
this
type
of
things
later
on.
I,
don't
think
it's
the
fundamental
in
here
I
have
just
one
other
question,
which
is
related
with
the
renaming
of
send
to
publish
and
the
reason
for
that.
D
Yeah
so
I
think
we're
initially,
it
was
sent
in
the
current
version
of
semantic
conventions,
but
we
as
in
in
Otep
and
a
bit
later
on
WE
introduced
new
terminology
which
uses
publish
I,
think
it's
just
the
general
message
and
terminology
that
they
are
great
too
before
you
join
Bruno.
So
I
noticed
this
inconsistency
that
it
sometimes
sentence,
sometimes
publish
and
I
move
renamed
Center
publish
where
possible,
where
it
was
inconsistent.
F
B
D
Yeah
yeah
I
think
I
will
relax
this
requirement
in
the
language
and
I
encourage
everyone
who
is
interested
to
review
the
current
version
of
the
pr
and
see
if
they
are
happy
with
with
this,
is
it
too
bad?
Is
it
not
like
to
bring
it
on.
B
And
I
have
another
question
on
here
that
I
wanted
to
bring
up
and
I'm
going
to
bring
it
up
now
because
we're
talking
about
that
right
away
and
it
concerns
basically
the
splitting
up
of
the
current
document
into
separate
documents
like
one
for
10
hours
by
teaching
semantic
conventions.
One
four
then
don't
know
I
think
we
have
rocket
mq,
rabbit
mq
and
the
Kafka
and
I
I
actually
was
wondering
better
I
mean
that's
something
that
I
I
could
do.
I
could
could
get
started.
B
I
just
was
wondering
whether
we
should
better
do
this
after
this
PR.
Here
look
middle
is
merged,
so
if
we
should
do
it
before,
do
you
think
it
would
make
like,
in
the
end,
having
a
reviewing
this
PR
and
putting
it
up
for
review
easier
to
have
it
split
up
already,
or
should
we
do
that
after
this
PR
here
is
done.
D
I
I
would
suggest
to
do
it
after
anything.
Before
we
start
splitting,
we
need
to
add
some
language
on
what
conventions
this
other
things
need
to
follow
right,
and
maybe
there
is
enough
language
in
this
VR,
or
maybe
it's
just
a
few
sentences.
On
top
of
that,
we
can
even
merge
this
two
strings
of
work,
but
we
don't
have
to
it's
just
or
you
can
go
ahead
and
like
I
mean
you
cannot
do
this
before
the
sphere
is
merged
because
it
introduces
the
start
of
the
naming
conventions
right
and
it.
E
B
Will
just
summarize
here
then,
that
we
will
just
relax
this
requirement
here.
Foreign.
B
Okay,
so
basically
we
will
relax
this
requirement
and
then
we
will
follow
up
with
the
discussion
in
the
future
to
kind
of
come
up
with
a
recommended
or
required
way
how
to
how
to
integrate
mqp
with
other
messaging
systems,
I
mean
it
could
be
say
or
others
other
similar
protocols
with
other
messaging
systems.
C
Just
because
I
don't
know
if
amtp
is
the
special
case,
so
much
as
JMS
is
more
of
the
special
case
like
JMS
is
a
standard
API,
but
can
have
many
different
providers
and
we
have
JMS
concerns
and
then
the
providers
some
protocol
underneath
that's
where
I
can
see.
You
can
have
two
systems
in
a
way
in
play
at
once.
C
D
I
think
it's
it's
still
relevant
anymore,
because
we're
we
decided
to.
C
Yeah
we
we
discussed
that
one
and
you
pointed
out
that
it
was
because
of
the
kind
of
tooling
that
it
is
this
way
and
I
was
fine
without
so
at
least
that
my
my
first
my
question
there
I
I'm,
not
sure
if
we're
talking
about
your
I
didn't
I,
don't
remember
your
comment
after
here.
I
didn't
do
that
just
now,
but.
D
B
D
Ison
yeah
folks,
please
do
and
if
you
think
we
can
move
it
from
the
draft
to
the
ready
for
review
I,
don't
know
either
approve
it
or
say
that
you
don't
have
major
feedback
in
some
way
and
ping
me
on
select
anywhere
and
then
I
will
try
to
do
all
the
changes
today.
So
if
you're
happy
with
it,
at
least
in
the
general
shape,
let
me
know
and
I
will
switch
it
to
the
ready
for
review
and
I'll
start
getting
more
feedback
from
the
community.
B
Yeah
I
actually
think
what
we
should
do
before
we
do
ready
for
video.
According
to
the
process,
we
should
create
an
issue
for
this
okay
and
I.
Think
creating
an
issue
would
be
would
be
really
good
here
because
remember
we
said
we
then
we'll
do
also.
We
also
need
to
discuss
how
we
will
go
about
these
changes.
B
We
will,
then
we
want
to
discuss
that
with
the
TC,
whether
we
should
have
basically,
first
this
change
and
then
later
on
have
other
changes
or
kind
of
late
till
we
have
all
our
breaking
changes
together
or
kind
of
do
several
steps
for
a
single
message
to
batch
scenarios
and
I
think
we
can
have
all
these
discussions
captured
actually
an
issue
and
then
one
stage
kind
of
figured
out
and
approved.
We
can
then
move
the
pr
from
draft
to
ready
to
review
if.
D
That
makes
sense,
then
I
will
create
an
issue
and
I
will
post
it
in
the
slack,
Channel
and
I
think
it
should
be
nice
to
folks
sums
up
on
it.
So
up
until
amateur
Community
recognizes
it's
the
community
effort
and
prioritize
it
and.
B
B
And
just
now
that
we
have
all
like
the
a
bunch
of
people
present
here
if,
if
latilla
opens
this
issue,
are
you
at
least
to
wearing
the
meeting
here?
Are
you
all
fine
with
having
your
name
mentioned
on
this
issue
as
kind
of
participant
into
discussion
to
get
this
up?
B
D
B
Public
summer
it
is
not
yet
published,
but
that
was
something
that
that
Josh
kind
of
told
me
and
I
think
it's
in
one
of
the
previous
I
know
it
might
be
a
bit
far
back
because
I
think
I
pasted.
B
B
And
by
the
way,
as
we
are
talking
about
this
now,
there
is
a
semantic,
a
general
semantic
conventions,
work
group,
that's
meeting
on
Monday
I,
think
10
p.m,
PST
that
is
led
by
by
George
Suarez,
and
that
is
about
basically
General
kind
of
a
general
route
to
stabilize
semantic
conventions.
So,
if
you're
interested
in
participating
there
I
think
I
will
try
it
next
week.
B
It's
on
the
calendar,
let's
see
here,
it
is
yeah
yeah.
B
B
It's
a
10
p.m.
A
10
A.M
Pacific
time.
D
D
The
daylight
savings:
okay,
yeah,
interesting,
okay,.
B
A
The
time
is
not
Europe
friendly
for
this
group.
C
B
Thanks,
okay,
so
we
have
this.
The
the
draft,
PR
kind
of
and
I
will
write
you
next
steps
open
issue
with.
B
So
I
think
we
have
discovered
yeah.
We
talked
about
these
terms
and
many
conventions
work
group.
Then
maybe
we
can
use
the
last
15
minutes
to
look
into
those
issues.
I
think
at
least
one
is
relevant
for
us
and
it's
this
rapid
mq1
and
what
is
asked
here
is
that
yeah
it's
met.
B
Each
message
has
header
attributes,
which
is
more
or
less
yeah
some
kind
of
key
value
pairs,
because
describing
metadata
on
this
message-
and
the
proposal
here
is
to
have
like
a
generic
way
to
add
I,
guess
all
or
selected
of
those
attributes
in
the
tunabic
way
determine
each
as
I
said
that
those
are
usually
like
key
value
Pairs
and
that
you
have
then
no
no
messaging
rabbitmq
message,
header,
Dot
and
then
the
key
here
in
the
attribute
name
and
then
the
value
after
that
and
I
think
the
one
question
that
was
brought
up
here
was
yeah
better.
B
F
Sorry
I
was
telling
I
was
going
to
tell
that
I
agree,
because
these
Heather
messages
they
are
not
most
likely.
They
are
specific
to
messaging
systems,
but
they
might
not
be,
and
if
they
are
specific
to
messaging
systems,
the
key
should
reflect
that
probably
some
recommendation.
It
can
be
introduced
on
that
regard.
But
yeah
I,
like
the
idea.
D
C
Sorry,
yeah
I
was
going
to
suggest
that
if
it
is
like
a
messaging
system,
specific
header,
I
I,
don't
know
if
it
should
be
a
generic
messaging.message.header
like
I,
think
it
should
be
kind
of,
as
shown
here,
messaging.system.message.header.
C
D
I've
done
some
research
on
common
attributes
between
different
systems
and
I'm,
not
sure
what
exactly
headers
are
in
rabbit
and
Q,
but
there
is
a
bunch
of
attributes
per
message
that
are
pretty
generic
and
I
I
put
the
names
here,
but
it's
it's
tentative.
There
is
no,
it's
not
documented
anywhere
else,
so
I
think
it
at
some
point.
D
We
should
Define
this
more
or
less
generic
things
that
are
common
across
different
systems,
and
we
can,
it
can
be
part
of
the
specification
or
it
should
be
part
of
the
specification,
and
then
the
guidance
would
be
that.
Okay,
if
this
thing
you
your
is
generic.
Yes,
that
use
the
generic
name.
It's
a
system
specific
or
it's
not
defined
in
generic.
We
use
the
it
in
the
system.
Namespace
yeah.
C
I
think
that
makes
sense
and
then,
if
it's
neither
sort
of
generic
nor
part
of
a
system
like
it's
more
of
an
application
layer
header,
we
could
entertain
a
way
of
putting
application
properties
in
as
well.
But
I
don't
know
if
we
should
go
that
far
or
not,
but
I
do
think
keeping.
If
it
is
system
specific
it
the
we
should
stick
to
the
message:
dot
system
Paradigm
for
adding
things
that
are
system
specific.
E
F
I
was
I
was
I,
was
defending
the
the
the
version
without
the
system
specific
because
I'm
I'm,
seeing
this
implemented
as
a
map
at
some
point,
and
we
can,
if
everything
follows
the
same
pattern,
it's
easy
to
have
just
a
map
under
messaging
blah,
blah
headers
with
everything
in
there.
F
If
we,
if
we
start
to
have
message
specific
headers,
it
complicates
things
a
bit
further
further
and
we
will
need
to
include
most
of
the
the
namespace
attributes
inside
the
map.
If
we
want
to
continue
to
have
just
one
which
I
think
it's
preferable.
A
D
And
HTTP
others
have
a
problem
because
it's
exactly
the
same
problem
as
we
are
going
to
have
that.
First,
they
had
attributes
like
content
plans
or
something
else.
I,
don't
remember,
host
header
right
and
later
on.
They
also
allowed
headers,
and
then
there
was
a
duplication
because
you
can
have
a
Content
lens
as
a
header
and
payload
size
as
an
attribute,
so
I
think.
If
we
can
avoid
it,
it
would
be
great
I'm,
not
sure
if
we
can
and
it
it
feels
that
we
we
will
have
to
admit.
We
will
have
this.
D
This
two
names
for
the
same
thing
problem
eventually.
D
The
header
is
a
bad,
very
undescriptive
thinking
messaging
provider,
sent
correctly
so,
for
example,
on
AIM
keep
your
message.
You
have
message:
annotations
delivery,
annotation
application
properties
and
all
of
this
are
called
headers
in
HTTP
world.
So
if
we
use
this
very
generic
term,
it
would
not
be
great
it's
what
I
at
least
what
they
think.
Maybe
Dwayne
has
an
opinion
on
this,
because
he
knows
much
more.
E
C
Yeah
I
mean
I,
guess
I
I
tend
to
agree
with
you.
You
know
more
or
less
for
the
reasons
you
you
say
there
and
envisioning
things
where
a
system
has
a
certain
header
value
that,
based
on
its
name,
sounds
very
similar
to
a
concept
of
something
that's
in
the
spec.
But
it's
not
that
it's
something
else.
C
It
would
just
be
nice
that
if
we
Define
certain
things
that
are
part
of
the
core
spec
that
you
only
included
at
that
value,
if
it
really
means
that,
and
if
you
have
something
system
specific,
it's
it's
identifiable
at
least
somehow
we
earlier
a
couple
weeks
ago,
we
discussed
whether,
where
that,
if
that
system
should
always
be
messaging,
that
system
or
could
that
system
appear
in
different
places
like,
for
example,
should
it
be
messaging
dot,
header
dot?
C
We
defined
a
bunch
of
things,
then
you
could
have
messaging.header.kafka
dot,
you
know,
but
we
just
we
kind
of
made
the
decision
that,
rather
than
allowing
system
to
appear
at
all
different
points
in
a
hierarchy
that
we
decided
to
put
it
in
one
place
so
that
everything
system
specific
is
at
this
kind
of
second
level
is
where
the
system
is.
C
If
we
stick
to
that,
then
I
then
I
would
rather
see
system
specific
stuff,
split
out.
I
I,
maybe
I,
don't
understand
the
value
in
I
understand
you
know,
Bruno
your
point
about
it
being
conceptually
a
map.
C
I,
don't
know
if
I
understand
the
value
if
back
ends
could
leverage
that
to
present
it
in
a
nicer
way
or
if
it's
more
of
just
a
human
understanding
of
the
information
presented,
I
I
from
a
human's
point
of
view,
just
if
you're
going
to
throw
all
this
information
at
them,
I
think
it's
helpful
to
just
kind
of
say:
okay,
this
is
system
specific.
You
know
very
early
on
in
the
name
and
then
you,
your
head,
aligns
with
okay
I'm
talking
about
ampp
specific
value
here.
B
I
I
like
to
share
this
to
you,
because
I
mean
when
we
say:
okay,
this
being
a
map,
I
think
it
will
be
a
map.
In
any
case
it's
just
here.
It
will
be
like
a
map
that
is
under
rabbitmq,
otherwise
it
would
be
basically
directly
message.head
or
key.
So
it's
a
map
anyway,
I
think
the
when
making
this
generic
and
basically
putting
this
on
the
message
level.
B
I,
don't
see
any
additional
benefit
actually
see
additional
sources
of
confusion
there,
because
also,
when
I
put
myself
lying
in
the
shoes
like
of
a
user,
what
benefit
do
I
get
from
that?
Like
actually
can
I
compare
those
header
values
across
messaging
systems
or
can
I
do
make
queries
on
those
I?
Don't
know
on
a
specific
header
value
that
then
goes
across
different
messaging
systems.
I
think
not
really
I
think
we
cannot
assume
that
any
of
those
headers
are
consistently
named
across
systems.
B
D
Like
maybe,
we
should
Define
some
of
them
for
some
systems,
for
example
for
GMS,
because
in
case
of
GMS
you
don't
have
anything
better
than
GMS.
You
might
not
have
anything
better
and
also
the
the
cognitive
load
right.
So
if
I
know
what
the
timestamp
is
for,
one
system,
using
at
least
the
same
name,
can
help
me
if
it's
the
same
thing
in
a
different
system,
if
I'm
searching
between
them
right,
it
I
think
this
is
a
philosophical
question.
The
Practical
one
I
think
header
is
redundant
and
not
necessary.
There.
B
Yeah
I
I
think
your
point
of
me
I
think
when
it's
when
it's
when
it's
a
concept
or
a
header
that
is
kind
of
common
to
several
messaging
systems,
then
I
think
we
should
move
it
out
of
the
header
and
kind
of
make
it
supported
attribute
in
the
semantic
conventions
and
not
really
treated
like
like,
like,
like
a
header,
into
think.
The
header
thing
might
be
only
used
for
things
that
are
not
covered
by
the
semantic
convention
stuff,
but
that
somehow
people
want
to
capture
in
like
a
ordered
way.
D
C
Yeah
I
agree.
One
one
point:
I
would
make
regarding
proper,
like
JMS
properties
today,
I
think
GMS.
Anything
that's
in
JMS
is
a
prime
candidate
for
something
to
be
in
the
core
messaging
spec,
because
it's
very
well
established,
but
also
it
has
many
many
implementations
right.
C
It's
there's
many
providers
for
JMS
and
JMS
has
a
specification
defining
the
meaning
of
all
these
things
and
so
to
say
something
they
I
think
it's
automatically
a
commonly
used
thing
if
it's
in
JMS,
because
of
how
many
GMS
providers
there
are
and
and
then
and
so
I
in
our
list
where
we
say
this
is
common
to
these
messaging
systems.
I
think
JMS
carries
a
lot
of
weight
because
underneath
there's
there's
many
systems
that
are
providers
for
JMS.
D
I
wonder
if,
in
scope
of
the
conversation,
what
should
be
defined
in
the
stacking
up,
inflammatory,
we
would
probably
say
the
GMS
and
I
agree
with
it.
We
probably
should
Define
it
in
the
general
spec
and
maybe
mqp,
and
then
everyone
can
use
attributes
to
find
for
those
two
if
they
are
used
in
GMS
or
if
they
were
covering.
F
I
think
we
should
be
explicit
and
everything
that
is
part
of
the
the
somatic
conventions.
It
should
be
here
not
pointing
to
to
the
GMS
specification.
We
can
say:
okay,
this
is
inspired
by
blah,
but
I,
think
jumping
and
connecting
the
two
is
a
bit
too
much
because
it
it
forces
people
to
go
to
the
GMS
specification
check.
What
that
is.
I.
F
C
Bruno
I
I
was
I
was
I
was
mainly
saying
that
not
that
we
should
refer
to
external
documentation,
but
just
that
anything
that's
defined
in
JMS
is
a
good
candidate
to
be
included
in
the
course
back.
Because
of
how
many
messaging
systems
would
have
that
concept
as
part
of
it.
F
I
agree
and
I
also
agree
with.
You
know
when
she
said
that
the
header
doesn't
add
any
information,
and
it's
true
because
it's
basically
saying
the
location
where
the
information
is,
it
doesn't
say
anything
about
information
itself
and
in
theory,
any
of
these
attributes
that
we
are
defining
here
can
be
on
the
header.
F
We
can
sorry
we
can
have,
however,
a
property
that
is
called
headers,
that
has
the
collection
of
headers
that
are
actually
on
the
message.
Just
I,
don't
know
just
to
people
usually
like
to
see
everything,
that's
on
the
headers
and
it's
good
for
displaying.
If
and
if
it's
ready
available
somewhere,
it's
it's
nice
but
other
than
that,
I
I'm.
Okay,
if
we
drop
the
header.
D
From
them,
if
a
friend
of
mq
defines
a
concept
called
header,
then
great,
but
if
MPP
system
defines
I,
don't
know
message,
annotations
I
would
rather
use
message.
Annotations
instead
of
colors
in
feather
is
not
it's
just
part
of
any
blood
that
goes
after
everything
queue
the.
B
B
It
mq
specific
headers
added
here,
but
we
don't
want
to
have
this
header
on
the
actual
in,
like
the
top
level
name
space,
and
we
rather
prefer
that
this
namespace
is
clearly
defined
and
that
basically
attributes
if
there
is
a
header
that
makes
sense
to
capture
or
that
is
consistent.
The
cross
messaging
systems
that
we
don't
capture.
This
is
header
attribute,
but
as
kind
of
a
dedicated
specked
out
attribute
on
the
message.
B
B
Okay,
we
are
right
at
time
thanks
everybody.
So
again,
please
have
a
look
at
a
final
look
at
Luke
meters,
PR
and
maybe
give
some
sign
of
acknowledgment.
Maybe
just
write
a
comment
that
it
looks
fine
to
you
and
then
we
will
go
ahead
here
with
creating
an
issue
and
then
continue
continuing
from
there.