►
From YouTube: 2021-12-01 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
C
Yes,
so
good
morning,
so
I
put
three
things
on
the
agenda.
I
thought
that
the
first
one
was
going
to
be
just
continuation
of
the
discussion
we
had
yesterday,
but
does
not
look
like
anyone
from
the
specs
group
joined
so.
B
I
actually
had
a
thought
and
yeah.
It's
a
shame
that
the
spec
folks
aren't
here.
It
seems
like
the
main
contention,
and
people
should
correct
me.
If
my
impression
was
wrong
at
the
moment,
is
that
we
have
written
into
the
specification
that
service
name
is
mandatory,
but
I
think
we
can
work.
The
specs
can
work
around
that
by
allowing
sdks
to
optionally
turn
that
requirement
off,
so
that
client
implementations
that
use
those
sdks
can
provide
different
kinds
of
signals.
B
So
I
think
this
is
something
that
could
be
worked
around
with
a
slight
exception
written
into
the
spec
it's
mandatory,
but
we
could,
but
sdks
could
provide
an
option
and
there's
not
very
many
sdks,
that's
going
to
be
relevant
for
right.
It's
javascript,
it's
java
and
it's
swift,
which
basically
only
has
this.
This
is
only
I
don't
know.
If
anybody's
writing
back
back-end
swift
codes
or
ever
will
there.
B
E
Is
there
just
thinking
out
loud
other
than
client
side?
Would
there
be
any
other
use
case
where
service
is
not
relevant
or
is
not
the
right
name.
B
E
D
B
D
B
B
C
So
so,
do
you
guys
think
that
I
should
split
the
this
pr
into
multiple
pr's
like
so?
Have
the
app
app
separate
from
browser
and
device
so
that
it
doesn't
sit
there.
C
So,
what's
what's
the
next
step
here.
C
Okay,
so
the
the
next
thing
I
was
the
next
two
topics
I
wanted
to
discuss
is
based
on
comments.
They
were
on
the
same
pr.
The
first
one
was.
C
C
So
so
my
question
is
like
is
like:
if
you
are
instrumenting,
if
you
have
instrumentation
or
sdk
in
a
browser,
then
should
these
be
required
or
should
be?
Should
this
be
optional?.
F
Indeed,
I
think
I
guess
the
context
is
that
they
are
anyway
present
in
the
protocol
level.
Headers,
so
just
duplicating
this
in
the
payload.
Just
for
the
sake
of
being
beautiful,
sounds
ugly
at
the
same
time,
so
not
even
sure
how
the
specs
should
regulate
these
cases
where
by
accident,
can
capture
some
telemetry
from
from
other
sources
than
the
actual
payload.
F
B
F
C
Well,
I
mean
it
is
optional,
but
I
can
say
like
if
the
if
the
user
agent
provides
these
through
the
http
header,
then
you
don't
have
to,
but
the
problem
then,
is
that
you
may
you
may
have
you
may
not
have
any
browser
attributes
at
all.
So
if
that's
the
case
I
mean
do
we
have
do.
We
need
to
be
able
to
identify
that
it's
coming
from
a
browser.
D
And
just
fyi
not
to
interrupt
too
much.
I
just
got
a
message
from
josh
saying
the
tc
folks
are
going
to
join
us
at
in
in
17
minutes
they're
in
their
weekly
tc
call,
then
they'll
drop.
Okay
got.
F
F
C
G
C
I
don't
know
it
looks
like
the
navigator
user
agent
is
available.
C
So
I
think
the
way
I
have
described
right
now
is
that
like,
if,
if
the
only
include
the
user
agent,
if
the
other
ones
are
not
present,.
G
C
G
E
Yeah
geolocation,
I
mean
it's
important
on
the
mobile
side
too,
but
I
don't
know
if
it
should
map
the
the
same
browser
namespace,
I
don't
know
like
geolocation
does
deserve
some
something
on
the
client
side
and
things
move
in
the
same
session
too.
Sometimes.
C
G
E
Not
necessarily
right,
it
depends
on
whether
so
so
there's
the
incoming
ip
address
option
and
then
there's
the
actual
lat
long
option.
A
customer
may
want
to.
E
G
G
C
Okay,
so
we'll
ask
them
when
they
join.
The
other
thing
that
I
wanted
to
ask
is.
F
Yeah,
it
has
come
up
few
times
where
the
current
restrictions
on
resource
immutability
kind
of
prevent
us
from
changing
app
name
under
resources,
service
or
b
service
name,
or
we
still
have
the
open
debate
about
that
name.
F
But
anyhow,
it
will
be
a
resource
and
resources
being
immutable,
prevents
any
kind
of
dynamic
behavior
there
and
the
multiple
tracer
kind
of
workaround
also
doesn't
fully
suit.
The
various
reasons
described
in
the
comments,
so
just
wondering
well,
is
there
anything
we
can
do
in
this
regard.
Other
than
saying
for
those
use
cases
which
don't
seem
to
be
that
rare
that
nope
everything
under
one
nap
name
and
that's
it.
C
C
C
F
B
Really
good
reasons
for
it
and
they
mostly
are
around
metrics,
because
the
resources
reported
along
with
the
metrics
if
the
resource
would
were
to
change
during
the
operation
of
a
particular
service
and
I'm
referring
to
service
here,
then
the
metric
dimensions
would
change
during
the
runtime
and
it
would
potentially
lead
to
cardinality
explosions
and
all
sorts
of
really
bad
problems
in
the
metrics
sdk.
B
F
C
I
think
there
was
there
was
a
concern
that,
like
the
use,
usually
the
web
applications
initialize
at
the
very
beginning,
whereas,
like
the
different,
the
different
applications.
Are,
you
know
when
you
have
a
single
single
page,
app
like
when
you
navigate
to
a
different
route,
then
at
that
point
the
initialization
is
already
done.
C
So
anyway,
I
feel
like
in
in
relation
to
this
pr
it
maybe
it
doesn't
block
the
spr,
maybe
that's
something
that
can
be
resolved
later.
F
F
C
All
right,
so,
I
think
we're
just
waiting.
E
C
C
D
D
C
So
we
wanted
to
continue
like
we're
ready
for
this
discussion.
We
wanted
to
continue
what
we
talked
about
yesterday
about
the
service
dot
name
yeah.
So
from
from
our
perspective,
like
we
have
two,
I
think
we
have
two
requirements
like
we
we
need.
First
of
all,
we
need
a
way
to
be
able
to
identify
client
side
that
the
telemetry
is
coming
from
a
client
side
instrumentation.
C
I
think
the
the
opposing
requirement
or
like
need
is
to
have
some
kind
of
way
to
identify
the
name
of
the
of
the
source
of
telemetry
right.
So
I
think
the
other
point
of
view
was
service,
dot
name
should
be
required
and
it
should
be
always
present
for
no
matter
where
it's
coming
from.
I
Yeah,
I
think
that's
a
good
recap
of
why
service
dot
name
is
required
and
why
it's
called
service,
because
we
started
with
back.
B
End
so
I
had
a
thought
about
the
current.
It
felt
like
what
the
sticky,
what
the
main
sticking
point
that
anthony
brought
up
yesterday
was
that
service
name
is
currently
marked
as
mandatory
for
sdks
to
admit,
but
I
think
that
we
could
actually
easily
work
around
that
by
just
creating
an
option
in
the
specification
that
sdk
may
provide
an
escape
patch
to
make
that
non-mandatory
for
client-side
sdk
implementations
or
for
client-side
instrumentation.
B
It
doesn't
feel
like
that
would
be
a
huge
step
to
just
say,
sdks
and
there's
only
going
to
be
a
couple
sdks.
This
is
even
relevant
for
it's
going
to
be
relevant
for
javascript
and
for
java,
and
then
eventually
maybe
swift
and
dart.
If
I
mean
swift,
probably
would
always
do
this
because
I
don't
think
anyone's
writing
back
and
swift
and
if
their
dart
sdk
ever
happens,
so
it
feels
like
it's
not.
I
The
the
real
question
is
so
someone
used
a
slippery
slope
argument,
which
I
love
and
hate,
because
we
don't
know
if
there
is
a
slope.
We
only
know
of
two
things
right,
but
the
there
if
there's
a
consistent
way
for
me
to
say,
give
me
a
name
attribute
for
this
thing
right
and
I
either
look
at
service
name
or
look
at
app.name
and
that
thing
consistently
exists.
It
has
to
that
there's
one
thing
that
has
to
always
exist.
I
If
I'm
in
a
context
where
I
don't
care,
if
it's
an
app
or
a
service,
I
just
want
the
name
of
the
thing
right,
but
the
the
thing
I
don't
want
to
lose
is
this
name
like.
I
don't
think.
That's
under
contention
here
right.
B
Can
you
know
enforce
that
as
they
need
to,
and
so,
if
I'm,
if
I'm
a
rum,
a
mobile
rum
library,
instrumentation
author-
and
I
know
that
the
wrong
back
end
for
splunk,
for
example,
is
going
to
be
looking
for
app
name
not
for
service
name.
B
Then
that's
something
we
can
execute
the
escape
patch
as
a
part
of
our
sdk
configuration,
for
example,
but
I
think
it
also
could
be
valuable
to
amend
the
spec
and
say
we
have
a
new
resource
attribute,
called
telemetry
source
name
or
something
like
that.
Just
making
stuff
up
that
will
default
to
being
the
same
as
the
service
name
or
the
app
name
or
whatever
the
identifying
teleme
the
kind
of
telemetry
source
that
will
go
into
that
same
attribute.
B
So
I
guess
I
what
I
want
to
make
sure
is
that
we're
not
just
saying-
and
you
brought
up
a
really
good
point.
Yes,
sir
yesterday
josh
that
you
know
we
have
the
technical
difficulty
and
the
community
education,
difficulty
etc,
and
those
are
two
kind
of
tensions
we
need
to
balance
or
figure
out
where
the
right
that
right
point
of
balance
is,
but
I
think
it's
actually.
We
don't
have
a
really
big
technical
problem.
I
think
we
can
very
fairly
easily
solve
this
issue
with
just
a
couple.
I
Then
I
yeah
we
should.
We
should
go
after
that
when
it
comes
to
resources,
though
I
have
two
concerns
that
I
think
we
need
to
pay
attention
to.
One
is
around
stability
of
the
names,
especially
when
it
comes
to
metrics.
I
So
I
know
that,
like
I,
I
think
that
this
group
is
mostly
focused
around
brahmin
tracing,
but
resource
is
going
to
get
reused
for
metrics
and
logs
and
that
sort
of
thing,
and
when
it
comes
to
metrics
and
alerts
on
metrics,
you
want
to
avoid
identifiers
that
have
a
high
cardinality
explosion
or
changing
identifiers,
because
you
can
actually
break
users
alerts
that
are
based
on
metrics
computed
with
this
resource
identifier.
I
So
one
of
the
things
around
app
name
that
I
wanted
to
ask
about
is
like
how
stable
that
sucker
is
or
like
what
things
you're
you're
looking
to
put
into
resource.
That's
just
one
thing
I
wanted
to
call
out
if
it
hadn't
already
been
talked
about,
but
the
second
thing
is
this:
do
we
need
an
open
telemetry,
a
thing
that
we
can
look
at
to
identify
a
cohesive
set
of
components
in
a
distributed
environment?
I
Like
that's
one
of
the
service
name
does
that
for
us
today
right
so
so
a
user
wants
to
say
here
is
my.
You
know,
checkout
service
right
and
that's
obvious
with
service
name.
Is
that
a
thing
with
apps,
because
I
think
it
is,
I
think
that's
what
you're
trying
to
use
app.name
for
of
like
here
is
my
you
know:
starbucks
coffee
rewards
app
and
I'm
tracking
all
the
usage
of
that
sucker
right.
I
Do
those
two
concepts
need
to
be
exactly
the
same
thing?
Is
it
okay
for
them
to
have
very
different
interaction
models
inside
of
the
sdk
right?
I
think
what
you're
suggesting
john?
Is
it's
fine
if
they're
totally
different,
and
I
can
totally
buy
that
because
I
think
again,
it's
a
back-end
concern
around
how
back-ends
unify
these
things
with
these
names.
B
Yeah,
I
mean,
I
think
we
already
actually
have
this
issue.
I
mean
right
now,
like
I
know,
probably
if
you're
using
the
raw
I'm
just
talking
for
java
here,
the
raw
sdk
and
you
haven't
pulled
in
the
resource
module
that
auto,
like
does
auto
resource,
auto
detection
and
that
kind
of
stuff-
and
you
don't
remember,
to
set
environment
variables,
which
you
know
the
first
time,
anyone
spins
any
of
this
stuff
up.
They
probably
don't
because
they're
just
using
what's
out
of
the
box,
they
get
a
service
name,
that's
useless.
B
It's
like
unknown
service
java
and
it's
not
useful
to
anyone
and
so
like
what
we've
done
in
the
splunk
distribution
and
I'm
sure
other
people
done.
The
same
thing
is
basically
make
make
this
mandatory,
make
it
something
you
have
to
specify
when
you
start
it
up-
and
I
think
this
is
we're
just
in
a
very
similar
situation
like
the
splunk
rum
distribution
or
java.
B
Instrumentation
library
requires
you
to
set
the
app
date
where
it
fails
to
start
up
and
your
application
just
won't
start,
which
is
clearly
something
that
the
user
will
not
not
be
able
to
avoid.
B
I
No,
the
the
only
complication-
and
I
think
I
agree
with
you-
that
we
can
specify
this
of
so
so
we
have
a
guaranteed
single
attribute.
We
look
at
right
now,
for
this
name
and
for
like
a
jager
exporter,
it's
an
absolute
requirement
that
you
have
a
service
name.
I
B
Spec
to
say,
there's
a
new
attribute
that
is
this
unique
name
that
is
always
written
to
from
either
service
name
or
app
right.
Yes,.
F
Okay,
wouldn't
the
single
attribute
now
get
us
back
to
where
the
interest
wouldn't
be
able
to
separate
whether
it's
kind
of
client-side,
telemetry
or
apm
side
element
well.
B
I
don't
think
we're
saying
get
rid
of
app
name
and
service
name.
We're
saying,
have
an
additional
attribute
that
is
kind
of
the
canonical
name
for
whatever
the
telemetry
source
is,
but
then
app
send
app
name.
Services
send
service
name
and
there's,
then
back
ends
can
easily
identify
from
the
resource,
whether
it's
a
service
sort
of
resource
or
an
absolute
resource.
F
B
B
F
B
B
I
Right
so
something
comes
from
a
service,
it
would
have
like
unique
name
and
service
name
or
whatever
the
heck.
We
call
the
the
universal
name
and
then
it
would
also
have
service
name.
If
it
comes
from
an
app,
it
would
have
universal
name
and
it
would
have
app
name
and
they
would
they
would
both
have
the
same
value.
We
should
probably
also
add
something
to
the
spec
around
how
you
can
drop
a
universal
name.
You
know
that
that's
fine,
if
you
don't
need
it,
but
yeah
yeah.
I
like
I
like
this
proposal.
I
B
One
thing
that
we've
we've
brought
up
and
I
don't
think
we
have
any
great
answers
to.
I
don't
know
if
we
have
any
experts,
but
that's
like
hardware
like
iot
devices
or
network
devices,
or
things
like
that
that
are
hardware
or
or
maybe
firmware
or
maybe
the
telemetry
is
built
into
the
firmware
or
whatever.
B
E
And
it
also
totally
depends
on
the
kind
of
iot
device.
In
my
opinion,
right
people
consider
like
a
tablet
that
is
attached
to
some
kind
of
a
console,
an
iot
device.
Also
that's
a
very.
E
Iot
device
from
this
little
temperature
sensor,
that
is
only
sending
out
data,
let's
say
once
an
hour
or
it's
only
supposed
to
send
out
data
when
the
battery
is
low.
Yeah,
it's
very
different
use
cases
and
it's
not
a
service
like
I.
I
don't
think
any
iot
vendor
would
can
like
call
it
a
service.
E
I
C
B
B
But
I
will
also
say
this
kind
of
mandatory
service
name
has
been
one
of
the
most
contentious
items
in
the
resource.
You
know
in
the
two
years
I've
been
working
on
this
project,
so
hopefully
maybe
maybe
this
is
kind
of
the
thing
that
will
provide
some
clarity
to
how
this
actually
should
all
be
working.
I
B
I
mean
I
know:
splunk
is
sending
it
sending
all
of
our
data
via
zipkin
and
it's
actually
kind
of
a
it's
a
pain
for
the
back
end,
because
we
can't
there's
no
resource
things.
Okay,
so
we're
we.
We
actually
miss
a
lot
of
good
features,
but
that
you
know
eventually
will
change
that
when
sierra
decides
it's
a
priority
right,
sir.
J
But
overall,
yes,
I
could
say
that
we
can
mention
this
discussion
in
the
next
specification.
Call
yeah,
that's
a
good
one,
even
even
before
any
change.
Honestly,
it's
up
to
you
but
yeah.
I
recommend
I
would
recommend
that.
I
At
a
minimum,
the
question,
then
maybe
this
is
for
carlos
too.
Is
this
an
otep
or
is
this
a
speck
pull
request
in
terms.
J
J
I
could
say
that
probably
we
would
require
no
tap
because
technically
this
is
something
kind
of
breaking,
but
at
the
same
time
something
small
so
when
when
in
doubt
create
an
issue
first,
if
you're,
actually
you
already
have
that.
Stick
to
that
and
only
open
the
attempt
if
things
need
more
time,
my
god
is
that
we
don't
need
an
uptip
for
this.
I
Okay,
so
then,
if
we
have
a
pull
request
here,
here
would
be
my
ask
if
you,
if
you
can
write
a
pull
request
with
this
proposal,
what
works
really
best
in
this
community
is
to
find
the
biggest
dissenting
voice
and
go
reach
out
to
them
personally
and
say:
please
review
this,
and
so
we
should
do
that
ahead
of
the
spec
meeting
and
let
them
know
that
we're
going
to
present
it
at
the
spec
meeting.
I
So
we
can
have
a
discussion
with
relevant
people
or
if
they
can't
make
it
at
least
their
comments
are
in
the
in
the
pr,
but
we
should
figure
out
what
I
don't
know-
and
I
don't
remember,
is
who
the
biggest
dissenting
voice
to
switching
service
name
to
anything
else
was,
I
actually
don't
remember
at
all.
I
I
I
don't
know
who
who
are
who
the
biggest
ideas
would
be
here,
but
I'd
recommend
posting
it
ahead
of
time,
at
least
at
least
a
week,
so
people
can
see
it
and
then
also
reaching
out
individually
to
people
in
hotel
and
if
you
need
help
knowing
who
to
reach
out
to
carlos-
and
I
can
help
out
with
that
john
can
help
out
with
that.
You
know
morgan
count
about
that.
Whatever,
like
let
us
know
who
who
we
need
to
send
this
to.
D
Yeah
trying
to
think
of
like
so
there's
yuri
because
he
would
know
jaeger,
but
he
might,
he
might
not
care,
I
don't
know,
there's
the
the
gentleman
who's
whose
name
I
forget,
who
I
think
came
here
last
week
and
was
on
the
spec
call
this
week,
who
had
the
the
other
pr
related
this
I
don't
know
as
well,
but
yeah
and
I
mean
for
things
like
this.
I
always
go
to
bogdan
because
he
seems
to
always
have
an
opinion,
but.
B
Yuri
it's
easy,
for
I
mean
our
jaeger's
specification
can
just
say
you
know,
map
this
new
thing
to
the
service
name
or
map
back
named.
We
have
to
do
that
for
zipkin.
Already
like
we
have
a
lot
of
whole
bunch
of
kind
of
weird
spec
around
how
we're
supposed
to
deal
with
stuff
for
zikan.
So
I
don't
think
it
would
be
a
big
deal.
It's
a
small
change.
I
think
to
be
here
and
honestly.
B
I
don't
think
we
even
have
a
jager
exporter
specification
right
now,
so
it
actually
has
been
a
sticking
point
for
a
long
time
that
the
specification
says.
Oh
yeah,
look
at
this
jaeger
documentation,
that's
the
spec
and
I
I
think,
is
a
terrible
specification.
Wait.
I
I
Okay,
I
didn't
pay
attention
after
you
opened
the
bug
and
someone
said
they're
going
to
help
you
with
it.
Okay,
awesome.
I
In
any
case,
do
we
need
do
we
need
anything
else
in
terms
of
that
topic,
because
I
think
I
think
that's
I
I
like
this
proposal.
I
agree
with
john
that
I
don't
think
it's
going
to
be
super
contentious,
but
we
still
should
socialize
it
as
much
as
possible
ahead
of
the
discussion,
because
that'll
just
make
things
a
lot
smoother
and
we'll
have
well-fought
arguments
at
the
time
and
less
arguments
that
pop
up
later,
no
actually.
I
B
Know
the
person
who
has
been
the
most
involved
in
my
memory
in
around
the
service
name
mandatory-ness
and
this
part
of
the
spec
has
been
christian.
Knowing
mueller
christian
noah
miller
seems
to
be
have
a
lot
of
deep,
have
done
a
lot
of
deep
thinking
about
this
problem.
So
he's
probably
a
really
good
person
to
reach
out
to
as
well.
I
C
J
Can
probably
yeah?
I
can
probably
help
with
that.
I
just
need
to
join
the
slack
channel
and
we
can
probably
talk.
C
Okay,
okay,
I'll
I'll,
select
you
in
there
soon
on
a
different
topic
before
we
sincerely
since
josh
and
carlos
you
are
here
in
this
meeting
before
you
joined,
we
talked
about
a
different
topic,
which
was
we
have
we're
also
in
this.
In
the
same
pr
we're
introducing
a
new
namespace
for
browser
attributes
and
one
of
the
things
we
realized
that
that,
like
the
the
things
that
we're
trying
to
describe
are
usually
sent
by
by
the
user
agent
in
in
http
header,
it's
like
the
user
agent.
C
It's
like
the
browser
name
version,
so
I
don't
know
if
they're
trying
to
decide
like
if,
if
like
the
sdk,
should
be
also
adding
these
attributes
to
to
the
resource
or
if
it
should
just
omit
them
like,
and
if,
if
you
omit
them
like,
do
we
even
need
to
document
it?
I
This
is
really
interesting
to
me.
Yeah,
like
I
know
that
the
user
agent
browser
information
is
incredibly
critical
for
server
logs
and
when
you
do
event-based
logging
in
structured
logs,
it's
just
like
it's
really
important
that
the
entire
together
telemetry,
so
I
think,
there's
value
there,
but
it's
not
a
resource
in
that
sense
right,
because
when
you
get
from
a
server
side,
when
you
get
that
user
agent
string
it
that's
tied
to
that
particular
thing,
it's
almost
like
baggage,
which
is
it's
an
issue.
This
is
a
really
interesting
question.
I
C
Yeah,
let's
see.
C
Here's
here's
the
pr-
and
there
is
some
discussion
on
that.
I
I
mean
from
my
standpoint:
I
still
need
to
read
through
it
sorry
yeah
yeah.
We
can
talk.
I
can
talk
off
the
cuff,
but
it's
not
going
to
be
as
valuable
as
if
I
actually
read
through.
What's
what's
being
discussed
here.
My
my
off
the
cuff,
though,
is
that
I
think
that
this
is
really
valuable
to
to
specify
whether
or
not
it's
in
resource,
I
think,
correlates
to
this
notion
of
app
versus
service
right.
I
I
I
feel
like
this
is
something
that
you
would
attach
as
baggage
or
like
to
all
the
generated
telemetry
for
like
a
trace,
so
that
you
can
correlate
your
trace
with
a
particular
client
later
if
you
needed
to-
and
I
think
that's
more
important
for
logs
and
events
like
structured
events
than
it
is
for
other
things.
I
think
the
cardinality
would
be
explosive
for
metrics.
I
C
Well,
I
mean,
I
think
I
think
originally,
what
we're
trying
to
do
is
so
this
original
pr
started
as
as
clarifying
the
device
namespace,
which
is
part
of
the
resource,
and
I
think
our
the
intent
there
was
to
to
clarify
that
the
device
namespace
is
only
present
for
client-side
telemetry
and
then
we
said
well,
okay,
well,
it's
not
browsers
are
do
not
have
a
device
but
they're
they
send
hindsight
telemetry
so
like.
If
you
want
to
identify
browser,
telemetry
then
like
we
would
have
this
browser
namespace.
C
C
But
then,
if
you
look
at
the
attributes
that
we
have
now,
all
of
them
are
essentially
sent
sent
potentially
sent
in
http
headers.
So
if
they're
not
required,
if
the
sdk
chose
like
not
to
not
to
add
them
or
it
could
not
add
them,
then
then
we
lose
that
right.
We
lose
that
way
of
being
able
to
identify
that
as
a
browser.
I
I
Interest,
that's
a
great
question
off
the
cuff.
I
would
say
I
want
browser
as
a
resource
like
resource
should
be
the
thing
that's
generating
the
telemetry
yeah.
Absolutely
user
agent
is
incredibly
valuable,
but
is
also
incredibly
limited,
like
you
use
it
on
the
server,
because
it's
your
only
option,
but
you
having
a
browser
resource
means.
You
can
do
more
clever
things,
that's
useful
for
users,
so
I
would
highly
recommend
if
you
can
start
with
trying
to
push
for
browser
as
a
resource
that
seems
way
more
valuable.
F
Then
comes
the
limitation
of
that
martin
previously
exposed
that
this
information
is
not
even
accessible
through
old
through
all
the
browser
apis.
I
I
Yes,
I
I
still
think
the
argument
of
having
browser
as
a
resource
is
is
important
there,
because
if
you
can
get
more
information,
you'd
be
allowed
to
versus
just
using
user
agent
right.
I
So
so,
if
you
consider
a
resource,
an
identifying
set
of
attributes
right
yep,
so
that
would
be
basically
in
in
the
resource.
You
would
have
browser.x
attributes
that
define
the
browser
yeah
that
the
user
can
use
to
correlate
like
here's,
this
kind
of
a
browser
and
here's
all
the
kinds
of
filtration
I
can
do
to
say,
give
me
you
know
all
of
the
ios
browsers
or
give
me
all
of
the
safari
browsers.
Give
me
all
the
chromium
browsers.
I
Give
me
all
the
specific
version
of
chromium,
browsers
or
whatever
right
from
from
that
standpoint
of
what
resource
is
meant
to
be
it's
kind
of
a
way
to
have
you
join
on
various
things
and
get
all
your
telemetry
correlated.
So
what
I'm
suggesting
the
browsers
the
resource
would
be
when
I
fill
out
those
attributes.
All
of
those
attributes
are
basically
defining
what
browser
this
came
from
and
it
can
be
beyond
just
user
agent.
I
It
doesn't
have
to
be.
If
all
you
have
is
user
agent
right,
but
it
can
be-
and
that's
that's
where
the
power
comes
in
for
the
user
is
you
can
actually
define
extra
things
that
they
can
then
make?
You
know,
charts
alerts,
reports
whatever
on
sure,
okay,
so
yeah,
when
I
think
of
a
resource,
I
think
of
a
thing
like
a
process,
a
server,
a
right
and
the
identifying
attributes
are
the
common
things
that
let
you
join
across
those
components.
I
I
I
think
browser
kate
says,
like
you
know,
if
you're
this
kind
of
a
resource,
here's
the
set
of
things
you
have,
if
you're
this
kind
of
resource,
here's
the
set
of
things
you
have.
You
have
a
very
clear
parallel
here.
You
can
say
if
you're
this
browser,
here's
a
set
of
things
that
you
know
you
have
to
provide
if
you're
this
browser,
here's
a
set
of
things
you
have
to
provide,
and
it
that's
to
help
people
know
you
know
if
I'm
writing
a
thing
that
looks
at
you
know:
opera,
browsers,
here's
what
I
get!
C
Okay,
so
I
think
what
I'm
going
to
do
is
is
just
leave
it
in
the
in
this
pr
and
and
say
like
if,
if
you
can't
provide
these
attributes
provide
them,
they
could
also
be
include
sent
as
http
headers
by
the
user
agent
itself.
But
if
the
sdk
can
provide
these
attributes,
it
should.
I
C
Yeah,
I'm
not.
I
think
the
argument
was
that
some
of
the
backends
just
look
for
the
http
headers
so
like
this,
it
doesn't
have
to
be
sent
in
the
payload,
and
sometimes
there
may
be
also
cases
where
you
cannot
get
it.
You
know
through,
like
the
client
client
api,
and
so
you
can't
set
you
can't
send
it
in
the
payload.
I
F
I
So
then,
what
I
would
do
is
optimize
the
spec
later
right,
if
that
makes
sense.
So
this
is
one
thing
I
think
we
we
might
need
to
do
a
bit
more
of
over
time,
but
in
the
protocol
we
don't
do
compression
or
inference
around
semantic
conventions,
and
I
think
this
is
something
that
would
be
an
interesting
space.
But,
for
example,
if
I
am
reporting
telemetry
with
our
protocol,
I
can
report
more
than
one
resource
at
a
time.
So
it's
not
guaranteed
that
you'd
have
the
same
user
agent
header
for
for
each
resource.
I
However,
you
could
optimize
and
say
if
there's
only
one
resource
right
and
it's
coming
from
a
browser
you
can
automatically
infer
from
the
user
agent
a
set
of
attributes
to
fill
in
if
you
want
to
use
that
as
a
compression
technique
is,
is,
is
that
the
concern
here
is
like
we're
worried
about
the
amount
of
data
we're
sending
out
of
these
clients.
F
I
think
that's
one
of
them
yeah.
It
is
indeed
one
of
the
aspects
of
it
duplicating
what's
present
at
the
protocol
level
in
the
payload
just
seems
silly,
but
it
might
have
its
merits,
because
the
worst
thing
is
that
it's
completely
unspecified
and
every
vendor
figures
out
their
own
way
of
how
to
how
to
build
this
notation.
F
I
So
I
guess
the
those
those
are
good
concerns.
I
would
say
from
a
semantic
convention
standpoint
the
when
you
think
about
resource
think
about
this
data
flowing
through
multiple
endpoints
before
it
reaches
a
back
end.
Possibly
so.
The
protocol
is
designed
such
that
you
can
have
more
than
one
resource
in
the
same
call.
I
However,
I
don't
think
it's
outside
the
realm
of
possibility
to
say
if
the
protocol
has
this
thing
in
and
we
want
to
infer
that
you
could
specify
that
and
figure
out
how
to
get
that
information
back
into
the
resource,
but
what
what
we
should
avoid
and
what
you
probably
you,
may
or
may
not
know
that
google
did
this,
but
we
should
try
to
avoid
limiting
one
resource
poor
per
otlp
ingestion,
but
that
that
is
something
that
I
think
if
we
start
specifying
that
it
highly
limits
what
we
can
do
with
our
collection
infrastructure.
I
So
I'd
be
a
bit
nervous
if
we
started
assuming
that
the
the
http
user
agent
of
an
otlp
you
know
bit
of
data
coming
down
was
the
identifying
thing
of
that
original
telemetry
right,
because
we
expect
telemetry
possibly
to
throw
flow
through
more
than
one
point
before
it
reaches
its
end
destination.
C
So
so
it
could
be
that
maybe
if
there
is,
if
there
is
like
a
collect,
maybe
the
collector
like
adds
the
browser
attributes
to
to
the
resource
before
the
batch
batches.
Then.