►
From YouTube: 2021-11-24 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).
A
A
Yeah,
so
I
I
think
the
only
the
only
thing
that
I
have
one
that
I
wanted
to
talk
about
today
is
just
those
two
prs
that
I
opened
yesterday,
so
that
some
people
already
commented
on
them,
but
yeah
I
just
to
the
channel
for
pointing
out
that
the
other
pr
in
the
slack
that
just
seems
to
contradict
the
one
that
I
just
opened.
So
I
think
we
need
to
talk
about
it.
A
C
I
think
I
think,
unfortunately,
we're
going
to
need
to
get
more
people
from
the
tc
and
the
general
spec
community
before
we
can
get
this
resolved.
D
Hey
so
so
this
is
severance
speaking,
I'm
the
person
opening
this
this
thing,
so
I
thought
I
I
jumped
onto
this
call
to
to
give
some
background
on
that,
so
I
never
aimed
to
to
to
jeopardize
the
goals
you
have
at
this
meeting.
I
said
in
in
the
discussion
there.
D
My
goal
is
really
to
nail
down
like
what
is
a
service
and
what
it
is
not,
and
I
have
a
strong
preference,
I
said
to
to
say,
like
hey,
everything
is
a
service
or
everything
is
an
application
or
whatever,
but
but
I
could
live
with
with
whatever
solution
the
the
community
comes
up
again.
I
I
think
I
I
have
been
a
web
developer
myself
and
I
would
be
okay
with
calling
it
a
service,
but
I
think
I
understand
your
rationale
to
to
to
do
it.
Otherwise,.
C
Yeah,
I
think,
the
so
something
we
discussed
actually
a
lot
in
this
meeting
back
end
providers
of
rum
like
rum
services
and
rum,
visualizations
and
etc,
really
need
a
way
to
distinguish
in
the
collector,
probably
between
telemetry,
that
is
coming
from
normal.
What
we
would
think
of
as
services
and
client
devices
like
web
browsers
and
apps,
and
this
the
spec
committee
has
made
it.
C
So
I
think
it's
going
to
be
very,
very
important
for
vendors
to
have
some
way
to
distinguish
between
these
two
types
of
telemetry,
because
the
analysis
that
we
do
is
very,
very
different
between
the
two
of
them
like,
for
example,
rum,
is
going
to
be
generating
events
which
are
going
to
look
like,
which
are
probably
going
to
be
backed
by
the
log
model.
That's
not
something
that's
going
to
probably
be
occurring
in
normal
services
at
all.
C
It's
probably
going
to
be
something
that
is
really
mostly
for
network
devices
and
perhaps
iot
devices
and
client
applications,
at
least
in
the
in
the
near
future,
and
the
processing
of
those
is
going
to
look
very
different
than
the
processing
of
kind
of
what
you
normally
think
of
spans
and
metrics
and
logs
from
a
service.
So
I
think
we
have
at
least
in
this
meeting,
discussed
quite
at
length
that
we
think
it's
very
important
to
be
able
to
distinguish
these
things.
C
D
D
I
have
at
hand
so
and
and
in
cases
where
you
don't
care
if
it's
an
and
client
app
or
a
back-end
app
or
a
database
or
whatever,
but
but
better
understand
where,
where
you're
coming
from
so
I
said,
I'm
open
to
to
to
change
the
specific
or
the
the
pr
I
opened
there,
but
I
think
there
need
to
be
a
common
consensus
yeah
on
on
the
general
specification.
I
understand
that
yeah
makes
sense.
C
D
That
was
the
initial
intent
yeah
this
this
was
so
so
just
to
to
give
you
some
background
where
this
is
coming
from,
so
we
had
some
internal
discussions
to
say
like
hey,
how
do
we
uniquely
identify
a
service
and
there's?
I
think
that
there's
even
an
open
discussion
or
an
and
telemetry
source,
so
whatever
you
want
to
call
this,
I
mean
it's
really
difficult
like
what's
the
name
of
that,
what
how
do
you
call
a
thing
that
sends
you
open,
telemetry
data,
so
normally
it
looks
like
in
the
specification
right
now.
D
It's
called
a
service,
and
I
agree
with
you.
Maybe
that's
not
a
good
name,
but,
but
that
is
what
it
is,
and
so
I
decided
to
to
open
up
this
pr
and
to
say
like
hey,
can
can
we
define
this
properly
so
so
that
we
can
then
in
implementing
our
backend,
be
sure
that
yeah
something
else
comes
up
and
someone
says
like
yeah.
This
is
not
called
service
anymore,
but
something
else
and
that's
exactly
what's
happening.
D
So
I
think,
that's
an
extremely
important
discussion
and
it's
extremely
important
to
have
two
things
in
a
glossary
because,
like
many
other
people,
I
I'm
a
little
bit
late
to
to
open
telemetry.
So
I
have
not
been
around
in
the
beginning
and
browsing
and
understanding
the
specification
is
sometimes
really
hard
and
the
first
place
I
normally
would
go
is
the
glossary.
So
that's
maybe
me
spending
too
much
time
with
mathematicians
to
just
check
like
hey
what
what
are
the
definitions
and
then
I
have
to
feel
like
there's
a
bunch
missing.
So
so
that's
that's.
D
Where
I'm
coming
from
to
say,
like
hey,
can
we
nail
down
those
those
those
definitions.
C
D
C
B
C
B
Yeah,
we
just
need
to
make
the
decision
either
way
right.
We
need
to
need
to
adapt
services
to
be
more
generic,
so
it
refers
to
basically
anything
or
or
delineate,
services
or
backend
services
run
clients
or
these
iot
clients-
and
you
know
these
other
things
are
these,
but
we
will
need
a
way
to
distinguish.
C
B
Either
either
versus
application
versus
other
things,
or
I
could
imagine
like
a
wow
brain
fart,
what
do
you
call
it?
A
like
a
not
a
boolean
but
a
you.
C
D
So
that
there's
some
some
cement,
some
attribute
where
we
sell
like
this
is
the
type
or
whatever
so
that
you
sell.
Like
I
don't
know,
I
could
just
left
like
in
the
telemetry
sdk
type
or
something
like
that,
and
then
you
would
look
into
client
or
app
or
something
like
that.
So
yeah
yeah,
I
mean,
I
said
the
problem
I
have
additionally
with
defining
something
like
app.
Is
then
that
you
said
like
hey:
we
have
app
name,
app,
name,
space,
app
version.
D
We
do
the
same
now
for
service
name,
service
version
and
then
you
copy
paste
in
in
the
specs.
And
then
someone
says
like
hey.
We
want
to
do
the
same,
for
I
don't
know
network
devices
and
then
suddenly
you
yeah
and
things
get
even
more
complicated,
but
maybe.
C
There
are
smart
ways
to
there
are
going
to
be
things
that
are
only
for
apps,
that
don't
make
sense
for
services
and
there
are
going
to
be
things
that
only
make
sense
for
network
devices
in
iot
devices.
There's
going
to
be
like
firmware
version
and
certainly
wouldn't
say,
service.firmware
version
that
doesn't
that's
a
very
strange
thing
right,
but
it's
gonna
be
very
important
for
iot
and
network
and
potentially
mobile
devices.
B
A
So
that
that's
all
I
that
I
had
that
I
wanted
to
talk
about
this
week.
Does
anyone
else
have
anything
else.
E
I
was
showing
the
pr
regarding
the
browser
semantic
mentions
to
our
team
and
they
came
up
with
one
question.
The
question
is:
do
we
want
to
be
future
proof
because
there's
a
boolean
flag
indicating
whether
the
browser
is
mobile
or
not,
and
the
question
was
is-
was
what
about
vr
or
ar
devices.
E
Exactly
so
currently,
basically
we
distinguish
between
mobile
and
non-mobile
browsers,
and
should
we
be
bulletproof
for
the
future?
Should
we
be
future
proof
if
there
is
a
browser
on
a
vr
device
which
wouldn't
be
mobile,
and
so
it
wouldn't.
A
A
So
so,
when
I
was
writing
this
that
that
spec
for
the
browser
namespace,
I
was
basically
taking
cop
sort
of
copying
the
attributes
from
what's
available
in
the
client
side
hints
for
user
agent.
So
that's
that's
in
you
know.
That's
that
comes
from
the
yeah.
I
guess
w3c
spec.
B
B
Just
because
we
may
want
to
decide
to
do
it
a
different
way
and
that
commits
us
down
a
path.
But
we
haven't
done
a
lot
of
research.
Yet.
E
I
do
agree
so
I
just
wanted
to
bring
up
the
topic.
As
the
team
was
asking-
and
I
do
agree
to
morgan.
F
Cool
makes
sense
if,
if
we
didn't
want
a
future
proof
I
mean.
Doesn't
this
make
a
good
case
for
an
enum
rather
than
a
boolean
flag
so,
like
today,
it's
only
mobile
or
you
know,
desktop
or
three
like
three
different
options
and
tomorrow
it
could
expand.
Just
a
thought.
F
I
think
stefan
brought
up
is
the
browser
mobile
or
not.
A
So
it
would
be
the
two
options
right
now
would
be
desktop
or
mobile.
A
G
Yeah,
I
wasn't
sure
what
the
next
steps
on
that
are
going
to
be.
I
think
I
was
I
mean
in
my
company
I'm
trying
to
get
a
few
members
aligned
so
that
we
could
start
working
on
the
implementation
and
contribute
to
the
individual
language
reports
on
implementing
some
of
the
things
we're
talking,
but
I
think
for
the
api
to
be
available
to
use.
C
G
No,
I
was
saying
that
in
order
to
define
the
api
spec
formally
for
the
individual
language
implementations
to
implement
the
apis
in
the
sd
case,
you
know
we
need
to
finalize
the
data
model
first,
which
is
still
pending
from
the
logs
sync
all
right.
So
until
that
happens,
you
know
we're
blocked
and
I
I'm
not
going
to
be
available
next
three
weeks,
so
I
don't
know,
I
think
whatever
looks
decides
whether
the
name
will
remain
at
the
top
level
or
you
know
field
or
we
have
to
use
the
you
know
attribute
for
the
name.
G
F
Martin,
I
only
have
one
question
on
the
app
dot
star
recommendation:
could
you
share
a
little
bit
more
about
the
space
and
how
you
imagine
that
to
be
used
a
bit
more.
A
Which
sounds
like
very
generic
like
if
you
want
to
you
know
if
you
have
a
use
case
where
you
want
to
group
multiple
applications
into
like
some
logical
group,
then
so
so
I
was
thinking
well.
If
that
applies
to
service,
then
why
not
to
client-side
apps.
G
Fair
enough,
it
does
have
one
useful
use
case,
which
is
let's
say
the
same:
app
is
available
for
both
android
and
ios
right.
You
know
you
could
put
them
under
same
name,
space.
F
G
F
A
A
Thanks
everyone
and
for
anyone,
who's
celebrating
thanksgiving
at
thanksgiving
and
if
not,
then
we'll
see
you
next
week
chefs.
Thank
you
all.