►
From YouTube: 2022-12-13 meeting
Description
Instrumentation: Messaging
D
A
E
A
You
know
here.
We
are
only
saying
that
the
event
page
view
you
know
consists
of
you
know
these
different
attributes.
So
this
is
in
some
ways
it's
achieving
what
we
want,
but
still
you
know,
strictly
speaking,
this
is
not
you
know
currently,
as
per
the
specification
spill
tools.
This
is
not
defining
that.
You
know
these
events.
You
know
these
attributes
belong
to
this
event,
although
it
is
giving
us
that
structure.
D
Yeah,
that's
probably
the
first
reason
why
I've
had
to
the
thing
here,
because
it's
not
really
representing
what
we've
been
talking
about
with
the
event
like
there
is.
There
is
no
event.data
here
and
from
a
semantic
conventional
perspective.
I
do
not
want
to
see
the
individual
Fields
going
browser.page.
D
D
F
E
E
We
just
what
is
this
PR
focus
on?
You
know
just
the
structure,
how
we
go
about
defining
these
things
and
then
start
looking
at
the
content
closely,
because
I
did
look
at
the
content
I
compared
to
the
docs
doc
that
it
came
up
with.
After
all,
the
good
discussions
and
stuff
trying
to
map
out.
You
know,
hey
page
view
here
are
the
attributes
we
wanted
to
Define
and
then
did
they
make
it
here.
E
A
A
You
know
where
they
have
listed
the
properties
of
each
type
of
object.
Right,
let's
say:
network
monitoring.
Has
these
properties
yeah,
so
I
think
the
the
idea
is
to
document,
and
you
know
that
way.
You
know
agreeing
with
each
other
what
fields
each
event
has
and
and
and
yeah
that's
that's
about
it.
E
Okay,
so
one
is
in
a
hardware
we're
going
to
structure
this.
How
do
we
represent
these
things?
You
know:
do
we
do
we
specify
the
actual?
You
know
the
data
with
the
structure
of
the
event,
if
you
will
or
not
so
that's
which
one
the
other
one
is
the
actual
field
names
and
stuff
and
which
Fields
make
it
in
the
page,
query
event
the
descriptions
and
the
examples
and
things
that
we've
already
come
up
with
right.
Transferring
that
information
from
the
document
yeah.
E
Okay,
so
I
I
understand
as
an
author
of
this
PR,
you
have
taken
some
Liberties
to
renaming
fields
and
things,
but
it'll
be
good
to
understand
which
ones
have
been
named
or
which
ones
are
mistakes
or
whatever
so
I
did
see.
You
know
feelings
that
are
missing
completely
or
renamed
completely
and
things
you
know
Ajax,
for
example,
I,
don't
believe
we
called
it
Ajax
or
maybe
we
did
in
the
one
document
you
know
so.
I
I
understand
that
so
I'll
start
commenting
on
that.
Also
I
will
probably
start
becoming
so
overwhelming.
E
E
E
E
A
A
E
So
that
Ajax
thing
was
my
bad
in
totally
called
it
page
view
of
the
fields
itself,
there's
discrepancy.
We
don't
need
to
spend
time
as
a
group
to
do
that.
I'll,
put
comments
in
the
pr
when
you
go
back
to
Nev's
comment
about.
You
know
the
structure,
you
know
the
do.
We
have
enough
information
in
the
dark
to
represent
things
and.
A
So
another
thing
is
this:
this
document,
I
I,
will
figure
out
a
way
to
push
to
the
JavaScript
repo
instead
of
the
spec
repo,
because
if
we
are
saying
that
we
we
want
to
introduce,
you
know
Fields
without
a
prefix
without
a
namespace,
I
I,
don't
know
if
it's
going
to
be
accepted
in
the
spec
repo.
Well,.
D
That's
that's
sort
of
where
I'm
coming
from
so
effectively
the
fields
without
a
prefix
are
not
semantic
conventions.
They
are
defining
the
field
for
the
event,
so
I
think
there's
there's
not
a
level
missing
here
in
that
we
should
have
saying
okay.
Well,
these
are
the
general
semantic
conventions
that
may
live
as
general
attributes,
probably
a
good
example
that
is
probably
HTTP
referrer,
so
very,
very
similar
to
the
the
set
of
bearing
attributes.
I
think
you
called
it
in
the
word
document.
They
should
follow
the
semantic
conventions.
D
A
D
A
D
I
agree
with
that:
it's
okay!
So
if
there's
already
one
defined
and
if
we
agree,
we
want
to
use
that
name
inside
of
data.
Fine
reference
it,
but
we
also
have
a
level
of
there
are
a
set
of
attributes
along
with
data
that
will
be
just
general
semantic
convention
ones.
So
if
you
go
back
to
I,
don't
remember
if
it's
the
word
document
or
the
Excel
I
think
it's
the
word
document
where
you've
got
the
varying
attributes
or
the
common
attributes.
D
D
A
F
D
A
I
think
I
am
after
and
I
can
make
it
explicit
clear
here
that
you
know
these
are
only
representing
the
the
payload
for
the
individual
events
and
on
the
wire
they
will
be
inside
an
attribute
called
event.net
I
can
rename
this
term
attribute
to
avoid
the
confusion.
I
can
call
it.
Let's
say
you
know,
field
or
something.
You
know
that
way.
You
know
all
of
you
know
this
structure
for
for
every
event.
Here
it
goes
under
event.data
yeah.
A
A
E
A
We
need
to
Define
them,
I'll,
add
them
at
the
top,
but
but
I
I
think
the
I
held
back
to
avoid
the
confusion
that
they
are
even
an
event.
You
know
they
yeah
I'll
word
it
carefully,
but
they
are.
They
are
going
to
be,
let's
say
the
way
the
you
know.
The
data
looks
on
The
Wire
Ram
is
there
is
one
object
resource
and
then
there
is
there.
You
know
there
can
be
an
array
of
different
types
of
events
or
spans
and
and
those
can
be
any
type.
D
A
A
D
Because
I
think
we're,
you
know,
I
think
if
you,
if
we,
if
we
clip
this
table
where,
where
the
table
is
you've,
got
like
a
browser.page.referrer.
If
that
said,
event.name
is
the
string,
it
has
to
have
the
value
of
page
view,
and
then
data
is
a
value
of
we
come
up
with
the
the
type.
Like
your
page
view,
data
yeah,
and
then
you
have
another
table
which
is
page
view,
data
which
then
enumerates
the
the
fields.
So,
let's.
A
A
A
A
F
A
A
D
Other
demanding
conventions,
yeah
yeah,
I
I've,
got
I've,
started
working
on
the
sandbox
and
hit
a
little
bit
of
a
roadblock
from
a
history
perspective.
So,
while
I
was
hoping
to
finish
that
by
this
week,
I'm
probably
not
going
to
and
then
based
on
that
I'm
not
here
for
the
next
or
not
available
for
the
next
three
weeks
after
this
week,
so
I'm
probably
not
going
to
get
a
lot
of
chance
of
this
either.
Based
on
my
current
background.
A
A
F
E
D
B
A
B
A
Think
it's
very
likely
that
we
have
to
move
away
from
yaml.
If,
if
we
were
to
you
know
not,
you
know,
have
references
like,
for
example,
HTTP
URL
is,
is
not
defined
in
this
document
itself.
It's
just
a
reference.
So
if
I'm
putting
this
PR
in
case
Ripple,
then
I
have
to
include
you
know
all
the
definitions
of
the
references
too.
So.
A
E
E
E
D
F
A
D
I
tried
that
with
my
original
event.data,
which
I
just
have
been
thinking
with
Maine
this
morning,
but
I
haven't
hit
it
since
the
last
couple
of
weeks
because
of
the
problem.
Okay.
So
so
what
I
mean
is
where
you've
got
the
in
your
yaml
file?
You
say
the
type
of
this
event
you
might
just
have
to
say
the
type
is
my
derived
one,
but
you're
probably
gonna
have
to
comment
everything
out.
Otherwise
you
know
the
the
build
validation
goes,
I,
don't
know
what
this
is
go
away.
A
D
A
A
C
C
Keep
the
like
spec
cig,
a
little
more
organized
in
general
about
what
which
projects
we're
taking
on
and
seeing
if
we
can
get
attention
a
little
more
concentrated
rather
than
spread
super
thin
like
it
is
now
and
I
would
love
to
use
our
existing
semantic
conventions.
Working
groups
as
like
a
test
run
for
this
in
January,
so
I
wanted
to
see
whether
or
not
this
process
felt
feasible
to
you
all.
C
So
the
basic
pitch
is
we
would
spend
for
each
domain,
so
this
we'd
browser
would
be
the
domain.
In
this
case,
we
would
spend
one
quarter
trying
to
get
the
group
organized
so
reaching
out
to
member
organizations
and
stuff
like
that
to
to
form
a
proper
working
group.
We've
already
done
that,
so
we
would
skip
that
phase
of
this
proposal.
C
The
group
wants
to
make
organized
so
then,
at
the
end
of
the
six
week
period
we
go
to
a
one
month,
public
review
period,
where
we
try
to
get
all
the
oteps
and
PRS
reviewed
and
then
merged,
and
then
there's
two
weeks
after
that
for
any
kind
of
like
cleanup.
That
has
to
get
done.
So,
if
oteps
got
approved
during
that
public
review
period,
then
we
would
have
two
weeks
to
turn
those
into
spec
PRS,
and
so
that
would
be
a
one-quarter
or
three.
F
C
Period
where
we
try
to
get
all
the
the
spec
work
done
for
that
domain,
and
then
we
would
have
one
quarter
after
that,
where
we
organized
people
to
actually
go
in
to
whatever
instrumentation
is
out
there
and
update
it
or
write
it.
So
what
I'm
curious
about
is
whether
or
not
this
group
feels
like
if
we
came
back
in
January
and
tried
to
to
work
hard
with
a
couple
TC
members
to
get
all
of
our
remaining
issues
banged
out
in
six
weeks.
A
It
it
would
certainly
be
great
to
have
TC
members
join
us
right.
That's
certainly,
you
know
something.
We
have
been
asking
for
yeah
yeah,
whether
six
weeks
would
be
sufficient.
It
depends
like
so
far
our
our
topics
have
been
controversial
as
in
they
won't
fit
in
the
existing.
You
know,
structure
you.
A
Yeah,
luckily,
luckily,
you
know,
even
that
there
is.
There
are
some
hope,
based
on
one
conversation
between
tigran
and
Josh
yeah.
You
know
where
they,
they
are
considering
addition
adding
an
additional
set
of
attributes
right.
So
if,
if
they
are
doing
that,
you
know
we
can
add
a
third
set
of
attributes,
for
you
know
that
that
can
be.
You
know
varying.
C
C
B
C
D
I
I
think
it
depends
so
for
the
browser-based
ones
right,
like
Santa's
Santos
has
already
made
some
good
progress
and
we
already
have
some
that
are
already
defined
and
sitting
in
the
spec
repo
yeah
or
are
the
ones
like
the
fact
that
we're
on
event.data
and
how
are
we
going
to
merge?
Cloud
events
in
I
think
six
weeks
is
optimistic
concerned.
We've
already
been
going
on
that
alone
for
several
weeks
in
the
log
Sig.
D
It
would
be
nice
to
push
it
and
say:
okay,
the
goal
is
for
this,
but
I
think
it
some
of
the
bigger
fish.
It
might
be
a
case
of
okay,
we're
going
to
get
this
big
fish
and
we're
going
to
dice
it
up
into
multiple
iterations.
That
would
probably
work,
but,
as
a
general
thing
saying,
everything's
going
to
be
six
weeks,
I
think
for
some
six
weeks
is
way
too
much
and
for
others
it's
not
enough.
A
D
Yeah,
it's
really
the
case
of
you
know.
The
braking
part
is
coming
from
the
discussions
around
Cloud
events
and
using
Cloud
events.
Api,
which
I
know
John's,
been
very
active.
John
Watson's
been
very
active
on
the
thing
and
I
agree
with
him.
We
should
not
be
saying
we're
going
to
consume.
Cloud
events,
API
I'm
I'm,
very
much
a
case
of
let's
look
at
the
cloud
event
specification
and
Implement
a
way
to
incorporate
the
spec
changes
into
logs.
So.
C
D
It's
a
little
bit
different,
so
so
there
was
the
it
was
in
Texas,
though
there
was
the
the
open
Telemetry
thing
and
the
cloud
events
guys
turned
up
and
sort
of
said.
Have
you
considered
this
and
when
you
look
at
their
spec
affected,
they
they're
covering
events
in
a
very,
very
broad
sense,
but
one
of
the
key
bits
that
they
have
in
there
is.
They
also
have
a
data
which
is
exactly
what
I've
been
pushing
to
say.
D
D
C
But
like
like,
we
don't
have
an
event
data
payload
in
the
sense
of
like
there's
metadata
and
then
there's
the
data
right
like
we're
just
metadata
we're
not.
We
don't
have
some
encrypted
payload
of
like
information
that
no
one's
allowed
to
look
at
and
that
kind
of
stuff.
It
just
seems
like
a
rapper
around
a
rapper
to
me
like
we
have.
We
have
a
log
message
with
attributes
on
it.
Why
do
we
need
like
a
blob
of
attributes
within
an
attribute
on
our
list
of
attributes
at.
D
Tigrid
has
a
PR
out
about
effectively
throwing
away
the
logs
the
the
logs
event
API
and
using
the
cloud
event
API
and
yeah
by
John
and
myself
and
I
think
other
people
have
been
very
active
and
okay
and
saying
all
we
want
is
like.
Let's
look
at
event,
the
the
cloud
events
and
say,
okay
and
at
some
point
in
the
future,
someone
may
want
to
go
and
create
a
bridge.
F
D
C
C
D
So
right,
but
Cloud
event
takes
a
little
bit
further.
Where
originally
we
were
saying
it's,
it's
the
nested
attributes
the
the
cloud
event.
Data
could
just
be
a
map
of
any
which
would
actually
be
nicer
from
a
browser
perspective
because,
rather
than
having
data,
have
a
bunch
of
attributes
which
has
a
bunch
of
additional
stuff
that
we
don't
need,
like
the
Json
would
be
name
is
this
type?
Is
this
value
is
this?
We
can
just
say
we
have
a
data
and
we
have
the
name
and
we
have
its
value.
C
D
C
C
So
right,
so
this
is
like
a
case
of
we.
We
have
like
a
couple
of
doozies
right,
like
this
events,
API
stuff
and
and
the
ephemeral
resources
things
that
are
like
bit
bigger
fish
than
we
would
normally
expect
the
semantic
conventions
working
through
to
end
up
needing
to
tackle
so
that
proposal
I
have
yeah
kind
of
presumes.
We
aren't
like
writing
the
logs
API
as
part
of
like
a
six-week
period.
C
The
semantic
convention
group
has
to
do,
but,
given
that
all
of
that
is
like
pretty
far
in
flight,
I
I
just
wanted
to
check
in
about
like
the
as
far
as
like
the
rest
of
this
stuff,
like
the
browser,
specific
stuff
and
hashing
out,
how
all
of
that's
supposed
to
work
does
that?
Does
that
seem
reasonable
for
six
weeks.
D
A
A
No
I
did
I
think
the.
Let
me
see
how
I
so
so
today,
you
know,
we
we
have,
let's
say,
are
a
log
record,
has
attributes
right
and
the
you
know?
Typically,
we
have,
you
know
different
attributes
and
one
of
the
attributes
is
event.data.
Now
what
value
goes
inside?
This
is
not
part
of
the
semantic
convention,
the
semantic
conventions
only
Define
the
attribute
key
names
attribute
names.
C
D
C
C
You
know,
agreement
from
the
TC
and
elsewhere
that
we're
going
to
focus
on
this
group,
starting
in
you
know,
hopefully
the
beginning
of
January,
but
maybe
we
start
two
weeks
in
or
something
like
do.
We
think
this
group
has
the
the
bandwidth
to
be
able
to
deal
with
that
attention
and
and
kind
of
like
get
everything
in
shape
in
six
weeks
who.
F
C
Be
I'm
not
sure
it
would
be
up
to
the
the
TC
and
like
the
spec
of
Purpose
Group,
to
decide
who
who
is
going
to
be
assigned
to
this
one
I,
don't
I'm
telling
them
it's
not
necessarily
a
requirement
that
they
be
like
domain
experts.
It's
just
that
we
when
we
go
into
public
review
for
a
month
like
when
we
actually
make
our
proposals.
C
A
C
A
C
C
C
A
C
A
C
C
C
B
C
Where
were
you
know,
especially
for
things
that
are
big
enough?
They
have
a
working
group
like
this
we're
going
to
like
explicitly
Define
the
scope
of
work
and
then
agree
to
like
pay
attention
to
these
projects
or
explicitly
say
no.
We
don't
have
the
bandwidth
to
pay
attention
to
this
particular
project
right
now,
so
that
one
way
or
the
other,
you
know
that
working
group
knows
what
its
fate
is,
rather
than
being
in
the
kind
of
state
where
they're
working.
But
it's
like
hard
to
get
attention.
C
A
F
C
Would
be
to
heard
this
in
messaging,
which
was
the
other
big
working
group
right
now
to
get
that
sorted
out,
okay
and
hopefully
to
get
some
some
PMS
involved
so
that
in
general,
we're
kind
of
organizing
the
backlog
of
oteps
in
a
way
where,
as
a
community,
we're
agreeing
okay
this
month
through
this
quarter,
these
we're
gonna
like
solve
these
problems,
because
right
now
we're
just
spread
very,
very
thin.
So
it's
like
not
clear
when
or
how
any
particular
Otep
or
or
project
like
gets
attention.
C
C
D
C
Oh,
you
mean
the
semantic
conventions
working
group-
oh
yeah,
yeah
I-
think
that's
gone
into
holiday.
Hell
at
this
point,
but
yeah
this
this
would
be
yeah.
We
wouldn't
be
trying
to
solve
all
this
through
that
working
group,
but
yeah.
That's
where
we're
trying
to
hammer
out
like
this
process
like
what
the
hell
is
this
this
process,
and
is
it
really
gonna
work
so
yeah.
D
F
F
C
It's
just
that
the
spec
Community
context
switches
like
crazy,
and
so
we
just
have
all
of
this
latency
built
into
a
lot
of
this
stuff
like
six
months,
is
like
silly
right
like
there's.
No
way
it
took
six
months
to
Hash
that
workout
most
of
that
was
just
air.
Where
you
know
someone
was
blocked
on
getting
somebody
else
to
pay
attention
to
it.
So
yeah
My.
B
F
C
A
C
Like
the
forcing
function
in
that
six
week
period,
we're
gonna
have
TC
members,
we're
gonna,
be
like
look
either
you
back
this
horse,
or
you
say
this
horse
is
dead
and
we're
gonna
like
make
a
new
horse,
and
so
like
one
way
or
the
other
like
we're,
gonna
pick
something
that
that
has
like
a
good
chance
of
making
it
through
the
public
review
period
rather
than
what
I
think
is
happening.
Now
is
like
we're
saying:
hey.