►
From YouTube: 2022-05-24 meeting
Description
Instrumentation: Messaging
C
D
Thanks,
I
I
bet,
but
but
briefly,
I'm
actually
going
to
be
out
for
the
rest
of
the
week,
so
I'll
miss
our
next
meeting,
but
then
I'll
be
back
for
for
a
month.
They'll
be
gone
again,.
D
Coupon
was
good,
you
know
I
mean
as
as
good
as
a
giant
trade
show
can
can
be,
but
there
was
a
huge
amount
of
open,
telemetry
interest
which
made
me
feel
good.
The
open,
telemetry
project
meeting
went
really
well,
so
in
general
I
thought
it
was
a.
It
was
a
good
time.
D
D
But
luckily,
luckily
some
people
had,
I
think,
maybe
new
relic
or
somebody
had
printed
up
a
bunch.
So
so
we
stocked
that
up
and
I
also
stole
their
remaining
supply
of
open
tracing
stickers,
because
no
one
needs
that
anymore.
E
Oh
cool
looks
like
we
have
actually
quite
a
bit
of
things
to
talk
about
today.
B
Sure
so,
basically
it's
all
mobile
related
and
for
the
first
point
we
have
very
tight
restrictions
on
device
dot
id,
so
we
are
specifying
exactly
what
must
be
used
and
the
point
is
for
there
are
certain
use
cases,
especially
privacy
related
concerns
where
you
don't
want
to
know
that
there
is
a
recurring
user.
So
what
we
in
dynatrace
do.
B
A
A
A
B
Browsers,
you
will
have
to
do
that,
but
ios
and
android
provide
possible
identifiers,
but
we
have
customers
who
are
really
concerned
about
privacy,
so
I
would
just
rephrase
it
so
that
customers
don't
ask
or
they
don't
need
to
ask
whether
they
can
generate
their
own
identifier.
So
I
would
still
opt
for
a
uuid
and
tell
them
okay.
You
may
generate
your
own
uuid
for
version
four,
if
you
want
to,
if
you
feel
you
have
the
need-
or
you
may
use
one
of
those
specifications
that
we
already
have
there.
A
Okay,
I
know
that
for
wi-fi
you
know
apple
and
android.
I
think
both
of
them
are
at
least
apple
for
sure.
You
know
they
don't
advertise
the
true
mac
address.
A
So
yeah,
I
think
it's
reasonable.
I
think
we
should
just
submit
a
pr
are
an
issue
at
least
to
start
with
and
see
if
there
are
any
objections.
Otherwise,
you
can
even
start
off
with
the
pr
to
see
what
people
think.
Well,
I
think
only
implementation
question
is
that
id
whatever
you
generate?
Will
it
be
persisted
or
will
it
be?
You
know
a
new
one,
each
time
those
are
actually
persisted.
B
Both
for
ios
and
for
android,
and
if
you
decide
to
use
them,
you
will
get
the
same
id
for
each
application.
Whenever
you
start
it
again,
I
would
need
to
look
it
up.
One
of
them
is
even
across
applications
of
the
same
vendor,
I'm
not
sure
if
it's
ios
or
android
now
so
don't
ask
right
now.
I
would
need
to
look
it
up
and
the
other
one
is
just
per
application
installed.
B
So
usually
what
we
do
in
niner
trace
is
we
generate.
We
don't
rely
on
those
values.
We
generate
our
own
uids
for
each
application
install
and
in
certain
cases
we
are
generating
them
and
we
are
not
taking
the
persistent
value,
but
rather
regenerating
them
per
session,
but
santosh.
Thank
you
very
much.
I
will
create
a
github
issue
and
also
start
working
on
a
pull
request.
A
B
B
Let's
say
that
the
real
version
of
android,
because
on
android
you
could,
by
the
means
to
query
the
human
readable
version
string,
that's
just
a
string,
so
it
will
give
you
anything
or
it
could
potentially
give
you
anything
and
we've
already
seen
in
the
wild
that
you
get
android
version
42
and
you
all
know
version
42
is
not
yet
released
or
not
being
released
in
the
near
future,
whereas
the
sdk
version
specifies
the
integer
number
which
application
developers
can
rely
on.
B
So,
for
instance,
you
will
get
sdk
version
21,
which
means
android,
5.0
and
developers
are
just
relying
on
this.
Are
you
referring
to
this
a
little
bit?
Actually
that's
the
telemetry
sdk
version.
So
I
see
this
as
completely
different
things.
So
for
me
the
sdk
version
is
the
device
sdk
version
which
specifies
the
sdk
that
an
application
developer
can
use.
So
if.
F
B
B
In
ios
no,
but
on
android,
since
it's
there's
an
android
open
source
version
as
well,
that
you
could
modify
it
to
your
own
needs,
you
could
report
any
arbitrary
version,
so
I
would
not
rely
on
the
version
string
in
our
backend
systems,
but
rather
on
this
sdk
version
to
say:
okay,
it's
exactly
android
this
and
this
version
yeah.
B
I
would
still
transfer
the
os
version
in
addition
to
this
sdk
version.
The
reason
is,
you
could
look
up,
what
does
your
operating
system
report
and
you
could
say,
okay
from
os
version,
it's
android
42.
I
know
there's
no
such
device
out
there,
so
whatever
you're
using
you're
not
using
something
that
we
are
supporting
officially.
A
Yeah
yeah,
I
think
yeah,
you
can
add
it
to
this
list.
I
think
it
it
qualifies
to
you
know,
go
in
this
list
as
an
optional
one,
not
a
mandatory
one.
I.
B
A
Yeah,
although
I
would
argue
that
that
is
also
something
that
doesn't
identify
the
research,
so
it
would
qualify.
As
you
know,
one
of
those
ephemeral
resource
attributes.
A
A
I
think
that
the
android
community
uses
the
terminology
sdk
version
exactly
so,
but.
A
Like
even
the
application
naming,
there
was
another
pr
from
stefan.
C
Just
I
thought
I
think
that
ted
might
be
able
to
answer
what
does
java
do
in
terms
of
reporting
the
runtime
version,
because
that
sounds
like
the
equivalent
here
and
considering
android
java
anyway.
D
That's
a
good
question.
I
know
they're,
like
kind
of
in
the
process
of
refactoring
their
semantic
conventions
around
recording
runtime
information,
but
I
imagine
they
would
just
follow
the
semantic
conventions
if
they're
available.
A
If,
in
this
community,
we
are
trying
to
converge
the
naming,
it's
it's,
it's
it's
a
good
thing,
but
it
can
also
be
confusing.
C
Yeah,
because
that's
one
thing
I
want
to
do
with
the
client
telemetry
is,
let's
just
define
the
common
set,
but
have
the
ability
for
vendors
or
specific
applications
to
define
their
own
type
of
events,
rather
than
it's
been
like
in
the
spec
meeting.
We
just
have
a
discussion
about
database
semantic
dimensions.
I
don't
want
to
do
that
for
clients,
because
we
have
way
too
many
more
events
for
clients.
B
That
sounds
nice,
so
basically
we
could
use
process.
Runtime
version.
B
A
A
C
D
B
Yeah,
so
the
next
one
basically
would
also
be,
or
it
could
also
be
changed
with
a
reboot.
There
are
use
cases,
especially
for
customers
who
want
to
ensure
that
the
device
is
not
rooted
or
jailbroken.
So
I'm
proposing
to
also
transfer
that
information.
B
So
you
might
know
you
can
root
your
android
phone
or
jailbreak
your
ios
phone,
and
I
know
especially
banking
customers-
want
to
know
that
information.
So
I
think
we
should
transfer
and
transfer.
B
D
D
C
That's
where
I
was
going
as
well,
rather
than
call
it
is
rooted
if
we
change
it
sort
of
said
it's
like
state
and
then
as
part
of
the
state
of
value,
you
could
say:
ios,
jailbroken,
android
rooted
or
you
know,
define
them
that
way.
So
if
something
else
comes
up
in
the
future
like
we
can
detect
that
it's
compromised
or
whatever
you
can
define
that.
D
Other
words:
it's
okay
to
create
a
namespace
called
ios
and
another
namespace
called
android,
potentially
I
think,
or
like
subname
spaces
of
some
of
these
other
things
like
device
and
process.
If,
because
there's
surely
going
to
be,
I
know
we're
talking
about
one
concept
right
now,
that's
somewhat
common,
but
there's
surely
going
to
be
concepts
that
are
more
specific
to
these
different
devices
like
certainly
the
browser
right
is
going
to
also
have
some
pretty
browser,
specific
concepts
that
probably
don't
translate.
C
Yeah,
like
probably
another
one
that
I
just
thought
of,
would
be
in
the
case
of
android.
You've
got
like
work
profile.
Maybe
you
want
to
send
that
back
if
it's
running
in
work
profile
mode
or
whatever
I
don't
know
throwing
stuff
out,
yep.
C
Well:
okay,
my
my
summary
of
my
own.
We
call
it
device
dot,
state
and
then,
as
part
of
the
values
for
device
dot
state.
We
could
then
use
namespace
like
ted's
talking
about
so
we
could
say:
ios,
jailbroken,
android
rooted,
genuine,
unknown
et
cetera
so
effectively.
We
just
define
namespaces
for
the
value,
not
namespaces
for
the
yeah.
A
C
Oh,
we
call
it
a
different
name.
Yes,
the
state
was
just
something
I
think
so,
but
yeah
having
or
we
define
it
as
semicolon
separated
or
something
if
we
just
want
to
keep
it
as
a
string
or
we
define
it
as
an
array
of
things,
I'm
open
to
all
of
those.
D
A
Called
you
know
what
what
is
this
concept
called?
What
is
wrong
in
just
naming
it
with
what
this
is
about?
Why
do
we
need
a
generic.
A
Yeah,
so
so
so,
if
we
can
come
up
with
some
name,
that
is
still
that
only
still
refers
to
this
concept
of
being
jailbroken
or
rooted.
I
think
that
should
be
good
enough
right.
It
doesn't
need
to
represent
others.
The
other
type
of
state
is
fine
question.
Yeah.
C
But
if
you,
if
like,
if
you
say,
is
rooted
and
then
you
say
genuine
that
doesn't
make
sense
based
on
that,
so
it
you
know
is
rooted
would
be
a
boolean
saying
yes,
no,
but
I
can
see
the
advantage
of
saying
you're
at
the
back
end.
You
want
to
collect
all
your
ios
devices
or
android
devices
so
having
a
separate
value
for
that.
A
Ios
or
android
is
already
determined
by
other
parameters
right.
You
know
you
don't
again
need
like.
Are
there
other
values
for
this?
You
know
parameter
like
in
android
itself,
you
know
other
than
android
or
rooted.
Is
there
any
other
possible
value
or
in
the.
C
B
There
are
some
things
that
you
need
to
test,
so
I
would
need
to
look
it
up
in
our
asian
code
what
we
do,
but
if
you
search
on,
if
you
google
it,
you
will
also
find
couple
of
answers
on
stack
overflow.
B
Basically,
I
mean,
what
would
you
do
you
know?
Okay,
somebody
was
rooting,
you
on
the
device
and
or
you
know
the
person
didn't
root
his
device
or
her
device.
B
Same
with
jailbreaking
so
either
you
know
it
or.
B
B
Then
maybe
we
put
under
so
usually,
of
course,
if
you
find
a
new
way
to
to
hack
your
system,
we
won't
detect
it
and
we
will
say:
okay,
it's
not
rooted,
it's
not
jailbroken,
so
we
detect
it.
Maybe
falsely
yes,
no.
A
So
then,
the
only
thing
we
need
is
the
name
of
the
attribute.
The
values
is
a
free
form
string,
not
the
boolean.
B
C
Because
I,
I
guess
in.net
potentially
you
could
report
whether
it's
secure
booted.
Maybe
I
I
can't
think
why
you'd
want
to
do
that.
But,
potentially
you
know
his
windows
phone
could
come
back
in
a
in
a
big
way
and
you'd
want
to
have
that
info
but
or
some
other
phone
could
come
along
or
I
wish.
D
There
could
also
be
different
levels
of
rooting.
You
know
like
like
this
is
like
a
kind
of
a
grab
bag
concept.
You
know
saying
something's,
jailbroken
or
rooted.
C
Yeah
yeah,
like
I
just
looked
at
this,
how
to
detect
on
android
and
the
fact
he's
looking
for
different
files
and
they've
got
like
six
different
forms
that
they're
looking
for.
So
I
I
don't
know
if
those
six
different
forms
represent
different
levels.
D
G
D
A
Yeah,
actually,
right
now
itself,
you
know
I
can
again
go
back
to
the
previous
point
that
the
moment
we
say
state
it.
It
typically
can
represent
or
can
include
multiple
parameters
right,
so
should
that
be
like
a
pipe
separated,
some
equilibrium
separated.
C
D
B
That
is
if
we
want
to
distinguish
between.
So
we
said
the
device
namespace
is
reserved
for
mobile
devices,
desktop
applications
or
desktop
devices,
any
anything
else,
except
for
browser
which
is
front-end
monitoring,
also
iot
devices,
and
maybe
we
would
like
to
distinguish
the
kind
or
the
type
of
device
that
is
communicating
here.
So
maybe
you
would
like
to
be
able
to
distinguish
mobile
devices
from
desktop
applications
or
iot
devices.
B
D
D
For
better
worse-
and
I
don't
think
we
have
to
do
this
everywhere,
but
we've
been
we've
taken,
the
approach
in
the
semantic
conventions
of
composition,
rather
than
then
rather
basically
detecting
the
presence
of
of
certain
keys
to
determine
these
kind
of
kind
categories,
rather
than
having
like
a
single
field
that
you
use
to
the
advantage
of
single
field.
Is
it's
like
easy
to
target
it,
but
the
disadvantage
is
you
can
end
up?
There's
often
these
like
complicated
edge
cases
right
like
what
about
android
being
run
on
a
desktop.
D
Yeah,
so
so
in
practice,
what
we've
in
general
taken
is
like.
We
try
to
avoid
those
kinds
of
kind
or
type
categories,
and
instead
say
you
should
you
should
be
detecting,
detecting
the
presence
of
attributes
to
determine
things,
so
you
know
detect
the
the
process
runtime
to
determine
if
it's
ios
or
android.
A
Actually
that
already
happens
like
I
think
the
you
can
only
query
for
maybe
these
parameters
from
the
you
know
device,
and
then
you
know
you
will
have
a
static
mapping
to
to
derive
what.
E
D
But
but
I
would
say
like
stefan
if,
if
there's
like
a
specific
thing,
you're
trying
to
drive
and
you're
saying
like
hey,
I'm
looking
at
these
conventions-
and
I
don't
understand
how
I
would
derive
this
information,
then
that's
like
a
sign
that
we're
missing
something.
D
But
but
we
should
avoid
adding
these
categories
unless,
unless
we
we
see
that
it's
like
not
possible
to
derive
that
information.
Just
from
the
presence
of
the
the
other
data
that
we're
already
reporting.
B
It
might
be
a
very
stupid
question,
but
that
would
be
something
that
at
least
would
be
interesting
for
me.
So,
just
out
of
curiosity,
assuming
I'm
building
a
front-end
application
as
a
mobile
application
in
the
windows
universal
platform
application,
would
there
be
a
possibility
or
how
would
we
distinguish
which
type
of
client
is
actually
coming
in?
So
of
course,
I
could
derive
this
based
on
the.
B
A
So
so
like,
for
example,
on
the
browsers,
you
know
the
user
agent
typically
includes
that
information
right,
so
the
user
agent
itself
is,
is
already
a
parameter
being
sent.
So
you
don't
need
to
send
another.
A
Yeah,
because
there,
the
user
agent
doesn't
apply,
there
is
exactly
yeah.
No,
I
think
the
point
is
we
should
send
just
the
minimal
set
of
attributes
so
that
the
rest
can
be
derived.
B
D
A
Translation
that
mapping,
why
do
you
want
to
put
it
on
the
client
on
the
server.
E
B
Okay,
maybe
I
I
didn't
explain
it
well,
so
the
derivation
of
device.model.name,
so
we
can
specify
it
but
for
mobile,
I'm
proposing
to
derive
it
on
the
back
end
based.
A
B
I
think
so
maybe
I'm
wrong,
but
if
you
find
the
presence
of
the
device
namespace,
you
know
it's
mobile
desktop.
So
it's
it's
it's
real
user
monitoring
and
non-browser
device
and
by
the
press
by
the
value
of
operating
system.
You
could
also
determine
where
it's
coming
from,
because
there
are
values
for
android
and
ios
already
defined
in
in
the
os.
D
You
know
what
I
mean
like
like
you're,
going
to
have
to
do
like
parsing
parsing
to
to
deal
with
this
and
that's
not
cool,
so
maybe
maybe
it
makes
sense
to
to
have
a
device
like
a
category
here.
That's
like.
D
D
D
Yeah,
I
see
that
because
the
I
think
the
other
information
actually
under
process,
runtime
name
essentially
right
if
you're
trying
to
figure
out
is
this
android
or
ios,
or
something
like
that.
D
So
you
would
be
like
okay
device,
this
device
kind,
okay,
I'm
more
sold
on
device
kind
being
a
thing
because
it
doesn't
really.
It
doesn't
get
captured
in
the
way.
This
information
that
that
information
is
captured
right
now
is
like
trying
to
figure
out
like
the
device
model
type
and
stuff
like
that,
and
that's
this
kind
of
like
a
never-ending
list.
A
Yeah
but
then-
and
I
think
the
main
question
is
you
know,
how
do
you
derive
that
device
kind?
Is
it
using
the
same
parameters
same
attributes
that
we
are
going?
We
are
passing
to
the
back
end
anyways
or
or
is
there
more
than
that.
D
D
Then
you
could
use
that
to
figure
it
out
right,
but
we
don't.
The
things
like
model
name
is
like
an
endless
list
of
slightly
different
values,
so
you
could
derive.
You
could
derive
that
I'm
running
on
a
you
know,
windows,
surface,
tablet
and
thus
know
I'm
running
on
a
tablet,
but
that
seems
like
expensive.
D
And
so,
if
it's
possible
for
whoever's
writing
down
these
resources
and
reporting
them
like
when
you're
starting
the
process,
if
they
can
know
that,
maybe
they
can't,
but
if
they
can
know,
okay,
I'm
this
is
actually
this
process
is
running
on
a
mobile
device
or
it's
running
on
a
desktop
or
it's
running
on
a
car
or
something.
D
Then
they
could
report
that
information
as
like
a
value
in
an
enumerated
list.
Does
that?
Does
that
make
sense.
A
I
think
my
my
question
still
holds,
which
is
even
that
enumeration
that
that
you
are
going
to
evaluate
too
you
know
you
will
what
will
you
base
it
on?
You
know
the
the
the
input
to
that
logic.
D
I'm
not
sure,
I'm
not
sure
it's
possible
that
that
it's
when
you're
booting
up
the
sdk
right
and
you're
filling
out
all
these
resources.
It's
not
it's
not
possible
to
know
some
of
this
information
like
do
you
know
whether
or
not
the
android
device
you're
running
is
running
on
a
phone
or
running
on.
D
D
D
Where
is
it
like
actually
feasible
to
know
this
information
at
boot
time
or
is
it
the
case
that
the
the
things
we
have
are
listing
here
are
things
that
you
can
know
but
they're
like
it's
not
very
easy
to
then
put
this
stuff
into
a
category
and
that's
actually
why
we
don't
have
device
kind?
Currently,
this
is
it's
not
it's
not
something
that
you
can
guess
reliably,
and
I
don't
know
the
answer
to
that.
I'm
not
enough
of
a
mobile,
modern
mobile
developer.
To
tell
you.
A
Actually,
that
is
another.
You
know
big
problem
in
in
our
team.
Here
we
need
more
representation
from
ios
and
android
side.
D
Yeah,
I
mean
likewise
these.
These
are
none
of
these
fields.
We're
looking
at
are
required
right,
which
implies
to
me.
It's
also
possible
that,
like
you,
can't
defend
on
model
name
being
there
and
again,
it's
not
clear
to
me
how
common
it
is
that
this
information
is
is
available.
I
imagine
it
is,
but.
B
B
E
So
this
this
leads
me
to
two
questions
to
you
ted,
but
I
think
I
I
asked
you
one
of
the
questions
that
I
sent
you
yesterday
yeah
so
for
for
this
kind
of
classification
question
like
when
vendors
are
ingesting
different
types
of
telemetry
and
they
need
to
decide
like
to
send
it
to
different
processing
pipelines.
E
D
Well,
I
mean,
I
think
you
can
use
whatever
you
want.
If
what
we're
trying
to
do
is
identify
ensure
that
there's
what
I
would
suggest
if
we
want
to
ensure
that
it's
possible
to
do
that
kind
of
data,
teeing
cheaply,
it's
worthwhile
to
write
down
how
that's
expected
to
be
done
not
as
a
requirement,
but
the
requirement
is,
would
be
more
focused
on
like
these.
D
Right,
I
think
it's
worth.
I
think
it's
worthwhile
that
this
is
coming
up
in
a
couple
other
places
right
where
we
just
said
in
the
past:
hey
resources
are
immutable
and
the
reason
why
that
was
stated
was
because
there
was
a
need
to
have
like
stable
identifiers
for
service
instances,
but
that's
not
good
enough
right,
because
there's
like
a
ton
of
resources
and
actually
what
we
need
to
do
is
get
more
specific
there
and
say
like
these
are
the
identifying
resources,
so
these
resources
always
need
to
be
present
and
we're
gonna
use
these.
D
This
combination
of
resources
to
to
fingerprint
services.
So
that's
one
example
of
a
place
where
we're
saying
we
need
to,
I
think,
go
back
into
the
spec
and
be
more
specific
about
what
the
purpose
of
some
of
these
resources
are.
And
so
I
think
that
would
be
helpful
for
this
group
to
to
do
as
well
to
to
write
down
our
intentions.
D
Just
get
the
intentions
into
the
spec
around
say
identifying
if
it's
mobile
clients
or
just
rum
data
like
I
do
think
it's
worthwhile
to
write
that
down
and
say,
like
our
intention,
is
that
all
of
this
client
data
is
going
to
need
to
get
identified
so
that
it
can
be
sent
for
additional
client-specific
data
processing
somewhere
in
the
processing
pipeline.
There's
client-specific
processing
that
we
know
we
want
to
do,
and
so
because
this
data,
somewhere
in
the
pipeline
might
get
mixed
in
with
all
the
other
data.
D
These
are
the
set
of
resource
identifiers
that
that
should
be
used
in
order
to
to
fork
it
off,
and
thus
these
are
the
resource.
These
are
like
the
the
same
way.
I
think.
A
I
think
one
practical
challenge
we
have
is
for
the
browsers:
it's
easy
right.
There
is
a
you
know
browsers.
You
know
they
are
never
present.
Yeah.
G
A
Back
ends,
whereas
device
you
know
there
could
be
onboard
devices
like
so
so
the
device
we're
not
sure.
It's
always.
You
know
client
telemetry.
Yes,
all
of
these
attributes.
Here
they
are,
you
know
possibly
valid.
Even
for
you
know,
devices
on
on
your
motherboard
or
devices
in
the
backend.
C
Yeah,
I
I
just
pasted
a
couple
links
which
I
think
helps
guide
this
a
little
bit
in
terms
of
because
of
the
upcoming
freezing
of
the
ua,
the
user
agent.
It
really
just
highlights
the
things
that
the
new,
secure
user
hint
stuff
grabs,
so
really
things
that
we
haven't
spoken
about
that
are
listed
are
like
architecture,
fitness
and
model.
C
C
Well,
this
is
for
a
browser
yeah,
but
you
know
it
really
is
a
case
of
like
a
lot
of
people
before
us.
Who've
already
like
struggled
with
these
problems,
so
yeah
just
trying
to
cut
down
and
say
well,
these
are
the
things
that
they've
identified.
C
So
should
we
consider
that,
as
well
like
in
the
case
of
the
secure
header,
it's
a
header
that
goes
back
to
the
server,
so
it
can
be
populated
on
the
back
end,
you
can
get
it
on
the
front
end,
but
yeah
generally,
you
do
it
at
the
collection
point.
D
D
We
need
an
otep
to
present
to
the
open,
telemetry
community
to
get
approved,
but
there's
also
a
need
for
us
to
get
our
own
thoughts
organized
and
make
sure
we're
we're
actually
representing
these
domains
correctly,
and
I
think
a
generic
data
model
otep
might
be
too
broad
and
what
I
might
suggest,
because
it's
kind
of
generic
and
what
I
might
suggest
is
just
breaking
this
down
into
a
dock,
a
dock
for
browser,
a
dock
for
ios,
a
dock
for
android
and
maybe
anything
else,
and
for
each
one
of
those
specific
things,
because
I
think
that's
a
level
where
you
can
now
get
very
specific
about
what
kind
of
data
you
need
and
in
each
one
of
those
docs
write
down
all
of
the
required
information
that
we
want
to
see
so
browser
resources.
D
D
D
Likewise
for
spans,
you
know,
write
down
in
the
browser
that,
like
you,
know,
event
handlers
get
captured
by
spans
and
then
do
the
same
thing
for
ios
and
the
same
thing
for
android
or
I
guess
in
ios.
I
should
say
for
ios
swift
right
like
and
and
get
actually
get
specific
for
what
should
be
captured
from
an
ios
swift
application
and
what
should
be
captured
from
you
know,
an
android
application
and
that
maybe
that
level
of
specificity
will
drive
out
any
anything.
D
D
D
If
you
look,
I
posted
a
link
to
it
in
the
agenda,
but
it
just
like
takes
all
that
information
and
instead
breaks
it
out
by
domain,
and
so
I
think
what
we
could
do
is
just
take
each
of
these
docs
for
each
one
of
these
practical
environments
where
we
want
to
get
this
done
and
then
in
those
docs
just
indicate
for
each
one
of
these
domains.
This
is
the
information
you
need
to
capture
right,
so
the
repetition,
I
think
there'll
be
repetition
right
like,
but
but
the
values
will
be
different.
D
You
know,
but
the
repetition
will
also
be
good
because
it'll
make
it
clear
where
we're.
D
You
know
where
the
overlap
is
between
where
the
commonality
is.
I
just
think
it's
more
like
I'm
thinking
of
this
less
as
an
otep
and
more
almost
as
like
an
exercise
like
if
we
break
it
out
that
way,
then
we'll
be
able
like
that's
something
you
could
actually
hand
to
like
an
instrumentation,
sdk,
rum,
developer
and
say
here
you
go
like
for
ios.
Do
it
this
way,
and
I
think
something
like
that's
like
in
practical
terms.
E
That
makes
that
make
sense
I
can
I
can.
I
can
do
that.
I
can
split
it
up
yeah.
I
think
the
the
reason
I'm
asking
is
because,
like
we
started
or
the
original
intent
of
this
otap
was
to
basically
define
that
we're
gonna
use
events.
D
Yeah-
and
I
I
don't
think
we
need
that
anymore
as
far
as
like,
like
we've
gone
to
the
community
and
convinced
them
that
we
need
an
events
api,
we
need
to
figure
out
where
we're
gonna
stick
sessions,
and
so
we
need
an
otep
proposing
sessions.
You
know
sessions,
resources
and
ephemeral
resource
otep.
I'm
willing
to
write
that
next
week,
when
I
get
it
back.
D
D
D
But
I
think
we
need
to
have
those
like
coherent
documents
and
we
could
maybe
even
get
those
added
to
the
spec
or
get
the
spec
rearranged
in
such
a
way
that
there's
a
section
for
each
one
of
these
major
run
times,
because
at
the
other
day
the
whole
point
of
the
spec
is
to
like
be
helpful
to
the
people
who
are
trying
to
actually
implement
this
stuff.
A
A
You
know
all
the
you
know
for
a
given
domain
in
all
the
you
know,
different
attributes,
as
well
as
you
know,
for
each
vertical
so
domain
as
in
http
is
one
domain
database
is
one
domain
where,
whereas
in
another
vertical
could
be
the
same
http,
you
know
when
looking
at
from
a
apm
perspective
or
from
a
client
telemetry
perspective,
or
even
let's
say
profiling
could
be
a
domain,
whereas
you
know
there
could
be
profiling.
Events
generated
on
the
client
side
and
in
the
application
side
and
other
places.
A
So
I
think
there
are
two
dimensions.
You
could
look
at
this
data
you
know
using
and
then
both
you
know
if
both
views
can
be
generated
automatically
with
you
know,
with
the
original
data
being
in
in
some
yaml
form.
That
might
be
one
way.
D
Yeah,
all
of
the
semantic
conventions
are
currently
auto
generated
at
a
yaml,
but
only
only
through
one
dimension,
but
yeah
yeah.
C
This
might
be
a
stupid
question,
but
as
part
of
combining
would
we
say
okay,
this
is
we're
going
to
define
event
x.
These
are
all
the
semantic
conventions
that
we
expect
to
be
passed
for
event
x,
but
then
also
define
where
those
conventions
might
be,
whether
it's
passed
as
a
resource
or
an
attribute.
C
D
Yes,
yeah,
I
think
I
think,
for
the
the
fields
where
the
values
are
are
knowable
or
it's
like
an
extensible
list
yeah.
It's
super
helpful.
C
Yes,
I'm
thinking
things
like
session,
we're
saying
we
want
session
to
be
as
a
resource,
so
we're
going
to
have
one
of
there.
So
for
eventx
we
can
say
well
the
session
id
for
this
event
is
here,
but
it's
going
to
be
passed
as
the
resource
as
opposed
to
other
ones,
so
it
might
be
possible
attributes
or
in
you
know,
embedded
objects.
D
Yes,
yeah,
I
I
think
I
think
it
is
worth
it
to
us
to
have
have
a
high
level
document
somewhere
that
describes
how
all
this
stuff
composes
into
something
useful
both
so
that
we
can
stay
sane,
but
also
so
that
future
people,
when
they
try
to
read
this
stuff,
can
stay
sane,
because
it's
kind
of
hard
right.
D
F
C
D
C
D
Yeah
and
that
could
either
end
up
being
just
docs
on
the
website
or
actually
baked
into
the
spec,
but
I
agree
that
that's
just
something
missing
right
now
is
a
high
level
design
doc
explaining
how
all
of
this
stuff
is
expected
to
compose,
but
I
think
we
can
solve
it
for
us.
I
I
think
for
us
the
best
way
to
do
it,
though,
is
to
to
maybe
break
it
down
by.
D
I
could
be
wrong,
but
breaking
down
by
like
browser
ios,
android
and
explaining
how
specifically
you
should
do
it
in
each
one
of
those
environments.
D
Find
commonalities
we'll
also
find
like
the
holes
in
our
like
our
our
own
knowledge.
I
think
it's
mentioned
like
we're,
maybe
light
on
on
mobile
people,
so
we
might
discover,
like
we
actually
have
no
idea
of
like
what
events
you're
supposed
to
capture
from
swift
or
how
to
write
them
down
and
then
we'll
know
like
what?
What
kind
of
expertise
we
need
to
get
into
this
group.
D
I
have
another
meeting.
I
have
to
go
down,
yeah.