►
From YouTube: IETF110-DISPATCH-20210308-1200
Description
DISPATCH meeting session at IETF110
2021/03/08 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
I
will
just
apologize
as
well
for
patrick
he
did
mention
that
jesus
some
personal
circumstances
he
might
not
be
here
for
all
of
the
meeting-
might
be
slightly
late.
So
you've
just
got
me
so
hi
everyone,
I'm
I'm
new
to
dispatch
chairing.
This
is
my
first
one.
So
go
easy
on
me.
I'm
kirsty
payne
from
uk
ncsc
and
it's
very
exciting
to
be
chairing
in
a
virtual
setting,
yeah
great
to
be
here
so
we'll
get
started.
A
We've
got
a
really
packed
agenda
for
today,
just
to
start
with
to
remind
you
of
a
note.
Well
so
for
many
of
you,
this
will
be
your
first
itf
session
of
the
week
or
it
might
be
your
first
itf
session
ever
so.
People
tend
to
skip
over
this
slide,
but
because
we're
early
in
the
week,
I'd
just
like
to
remind
you
of
all
the
various
processes
and
itf
policies
that
we
have
any
ietf
contribution.
A
It
might
be
your
first
virtual
session
in
itf,
so
use
a
headset.
If
you
need
to
add
yourself
to
the
queue,
then
please
add
yourself
to
the
queue
you
can
raise,
hands
and
keep
yourself
muted.
Unless
you
are
speaking,
you
don't
have
to
worry
about
blue
sheets
and
they're
automatically
taken
thanks
to
the
meat
echo
tool
and
you
can
have
chats
as
you
are
in
jabba,
that's
great.
But
if
you're
rounding
on
an
important
point,
please
think
about
bringing
that
to
the
queue.
A
So
you
have
notes
being
taken
and
we
also
have
jabba
and
if
you're
unsure
of
how
any
of
the
meat
echo
stuff
happens
or
what's
going
on
pop
something
in
the
chat
the
folks
are
around
to
help.
There's
also
the
participant
guide,
if
you're
stuck
on
what
the
tools,
how
the
tools
work.
A
Okay,
so
welcome
to
dispatch.
It's
our
virtual
meeting,
it's
nice
to
see
you
all
here.
We've
got
a
very
packed
agenda,
so
split
it
into
two
parts
and,
as
you
know,
we
cover
the
art
general
area
as
well,
so
to
start
with,
we'll
just
go
through
and
look
at
the
agenda
and
welcome
everyone
in
and
we've
got
date
and
time
on
the
internet.
First
then,
media
types,
content,
types
and
related
terminology,
then
some
http
content
negotiation
using
profiles
and
for
the
second
part
of
the
agenda
we
have
the
art
area.
A
So
this
is
not
topics
to
be
dispatched,
but
just
general
topics
of
interest
and
a
time
to
kind
of
air,
the
views
and
air
or
technologies.
So
we've
got
apn
as
the
first
slot.
Thank
you,
log,
sdp
mapping
and
zip
extensions.
After
that,
as
you'll
see,
we
leave
zero
minutes
for
aob.
All
times
are
utc
as
well,
so
just
whatever
timezone
you're
in
please
adjust
to
that
cool
and
as
a
reminder,
we
have
mailing
lists.
A
A
Okay,
all
right,
let's
crack
on
then
so
first
stitch
dispatch
topic
of
today
is
date
and
time
on
the
internet,
so
yeah
I'll
be
driving
the
slides
for
you.
But
if
you
just,
I
think,
add
yourself
to
the
queue
and
then
we
can
get.
B
That
might
be
my
headphones
and
I've
requested
a
screen
share.
Wait
I
can,
would
you
work
the
slides
or
can
I.
B
Perfect,
thank
you
so
hello,
everyone
and
let's
talk
about
date
and
time
on
the
internet,
I'm
mujwal!
I
work
at
this.
Consultancy
called
galia
and
if
you
find
that
easier
to
pronounce,
you
can
call
me
rizzakookan.
So
let's
can
you
progress
the
slides
please.
A
Audio
just
got
very
strange,
I
don't
know
if
you
changed
something
when
I.
A
B
Oh
okay,
okay,
so,
specifically
inside
of
tc39,
I
am
a
part
of
the
temporal
champions
group,
which
is
a
group
that
has
been
tasked
specifically
with
standardizing
an
update
to
the
javascript
date
object,
which
is
a
a
constant
pain
point.
So
they've
been
working
on
a
modern
ergonomic
api
for
building
daily
time,
applications
on
the
internet
and
there's
a
bunch
of
really
cool
people
in
this
subgroup
as
well.
B
Would
you
progress
the
slides
okay?
So
what
is
so
special
about
temporal?
I
am
a
little
biased,
maybe
you
could
say,
but
we
have
come
upon
something
which
is
a
modern
ergonomic
api.
It
addresses
some
of
the
long-standing
weaknesses
and
we
use
3539
as
the
base
interchange
format
for
the
different
objects
that
we
use.
B
We
also
have
first
class
time
zone,
support
and
first
class
calendar
support
for
the
different
apis,
which
is
is
something
of
the
first
in
our
space,
which
means
that
now
we
have
different
objects
which
have
time
zones
and
counters
inside
of
the
data
model.
And
then
you
could
ask
well
how
does
one
persist
that?
How
does
one
persist
a
time
zone
that
is
attached
to
a
date
time
or
a
time
stamp?
B
Could
you
please
progress?
The
slides.
B
Okay,
so
this
is
the
standard
timestamp,
as
one
might
expect,
according
to
3dz
9,
and
if
you
progress
the
slides,
you
would
see
that
the
time
zone
conundrum
is
is
a
special
one.
It's
a
special
one
because,
fortunately,
or
unfortunately,
we
are
not
the
first
people
first
group
of
people
to
to
come
upon
this
problem.
B
369
and
the
underlying
iso
standard
8601
allows
absolute
offsets
from
utc,
but
many
applications
all
over
the
internet
work
in
the
context
of
what
one
may
call
a
human
time
zone
and
of
course,
you
need
to
encode
the
timestamp
for
persistent
or
for
persistence
or
for
interchange
inside
a
database
or
to
just
round
trip
across
clients
and-
and
you
could
ask
well
what
is
a
human
time
zone?
B
Is
it
a
time
zone
that
is
that
is
included
in
the
list
of
time
zones
by
anna
or
is
it
as
specified
by
unicode
and
well?
The
group
of
people
that
came
across
this
problem
includes
people
from
developing
applications
all
over
right,
there's
java,
which
built
a
similar
api.
There's
linux
tools,
like
date,
there's
databases
and
then
there's
calendar
applications.
So
if
you
progress
the
slides,
you
would
see
that
now
it's
common
even
on
the
internet,
to
come
across
a
time
stamp.
Quite
like
this.
B
Now
it's
my
local
time
zone,
but
you
could
see
that,
apart
from
the
time
zone,
there's
a
suffix
that
that
includes
a
an
identifier
for
my
time
zone.
If
you
propose
the
slides,
there
is
another
variant
which
includes
the
iana
time
zone
and
the
next
one
would
be
this,
and
this
is,
I,
I
believe,
a
format
that
is
quite
popular
at
this
point
now.
B
So
if
you
move
ahead,
the
question
is:
are
we
done,
and
the
answer
is
unfortunately,
not
quite
this
format,
first
of
all,
was
never
standardized
java
or
whoever
first
came
across
this
just
just
move
ahead
with
this
without
ever
sanitizing
it
and,
of
course
one
of
the
big
problems
is
that
there's
so
much
more
information
that
can
be
encoded
for
us
specifically
in
temporal
calendars,
are
a
big
priority.
So
we
need
calendars
for
all
of
these
things,
I'm
sorry
and
what
else
we
can
have
cldr
time
zones.
B
We
can
even
have
time
skills,
so
there
is
in
fact,
a
need
for
a
generalized
format
that
that
is,
that
provides
people
a
way
to
form
to
format
extensions
in
a
way
that
that
is
agreed
upon
and
generalized,
instead
of
just
just
coming
up
with
ad
hoc
designs
that
don't
play
along
well
with
each
other,
possibly
and
there's
also
a
need
for
a
process
to
specify
these
keys,
the
different
information
pieces
of
information
that
can
be
added
and
the
list
of
acceptable
values.
B
So
if
you
move
ahead,
this
is
something
close
to
what
we
came
up
with.
I
changed
the
time
in
the
okay,
so
on
the
left,
you
would
see
what
we
usually
see
but
towards
the
end,
there's
another
piece
of
information,
and
this
is
a
tag
that
includes
a
more
generalized
form
of
including
any
information
in
the
timestamp.
B
So
moving
ahead,
we
could
see
that
temporal
could
utilize
this
format
to
to
have
its
own
extended
version
of
359
strings,
and
so
we
can.
We
can
use
this
to
express
what
the
calendar
is
like,
but
hypothetically
sorry,
ideally
one
could
use
this
to
include
any
information.
B
Yeah,
so
this
is
a
link
back
to
the
to
the
draft
that
I
came
up
with.
We
tried
as
tc39,
to
share
observations
with
ietf
to
to
upstream
one
could
say
this
format
to
the
standard
track.
We
tried
keep
folks
from
calconnect,
which
is
the
liaison
for
iso
in
the
loop.
The
goal
was
to
standardize
generalized
and
optional
extensions,
as
well
as
modernized
339,
which
is
gone
out
of
sync.
B
We
were
trying
to
also
standardize
a
mechanism
for
registering
these
keys
quite
similar
to
how
bcp-47
does
and
we've
been
working
simultaneously
with
unicode
folks
for
coming
up
with
a
new
namespace
for
these
things,
so
that
you
know
time
zones
as
well
as
calendars
as
specified
by
the
unicode
consortium
could
work
moving
ahead.
We,
the
question
now,
is
how
do
we
move
ahead
with
this
right?
B
We
brought
our
findings
to
the
calyx
working
group
as
well
as
calconnect,
which
happened
to
be
the
two
sort
of
big
bodies
that
deal
with
these.
These
changes
in
this
space
right
we
also
the
drafts
which,
with
the
express
goal
of
obsoleting
339
with
these
optional
extensions.
So
of
course
everything
that
is
accepted
right
now
is
still
accepted,
and
we
included
updates
with
these
optional
extensions.
B
B
The
question
that
now
we're
grappling
with
is
can
both
be
accepted
and
if
they
can,
then
then,
by
which
working
group
specifically
and
do
we
even
have
a
working
group
that
that
deals
with
this
or
do
we
need
a
new
one,
and
that
said,
if
you
progress
to
the
next
slide,
thank
you
for
having
me
here.
That's
it.
A
Great,
thank
you
for
your
presentation.
So
we've
got
time
now
for
discussion.
I've
seen
there's
a
lot
of
java
chat
going
on
any
kind
of.
If
we
focus
on
the
dispatch
questions
here
as
well,
do
we
think
this
work
is
valuable,
belongs
in
the
itf
and
where
would
it
go?
Where
should
it
go
so
I
can
see
I've
got
pete
in
the.
A
F
We
have
to
see
if
all
this
stuff
works
yes
morning.
So
first
one
quick
question
which
is:
does
anybody
have
a
sense
of
what
cal
ext
thought
of
this
like
which?
What
direction
did
the
discussion
go
in
there.
E
Yeah
as
calyx
chair
I'll
pop
in
to
comment
on
that,
assuming
you
can
hear
me,
it's
telling
me
attention
you're,
not
detecting
audio,
but
I
think
that's
that
wasn't
talking
to
start
off
with
thanks
signal
all
right,
positive
to
the
idea.
With
some
caveats
of
this
is
complex.
We
probably
want
to
spend
some
time
talking
about
it,
but
very
negative
to
the
idea
of
obsoleting
rfc
3339
and
defining
a
complete
format
that
included
everything.
E
F
Okay,
and-
and
so
that
brings
me
to
question
two,
which
is:
can
you
give
an
example
of
where
such
a
thing
would
be
used
to
express
a
time?
I
understand
for
calendars
like
expressing
ongoing
things,
and-
and
you
know
that
that
makes
sense,
but
for
expressing
a
single
time,
why
is
it
important
to
mention
the
locality
beyond
to.
E
G
Yes,
thank
you
so
in
in
the
jabber
room.
I
already
pointed
out
that
in
in
the
sibo
working
group,
which
is
actually
meeting
in
the
next
slot,
we
have
a
draft
defining
a
sibo
tag
for
time
now.
Sibo
already
has
two
tags
for
time,
one
for
rfc
339
times
and
one
for
posix
times,
but
it
has
turned
out
that
we
we
need
more
detail
in
time.
G
So
in
essence,
what
what's
happening
is
that
we
are
defining
a
little
information
model
for
time
and
I'm
wondering
how
we
can
make
sure
that
that
what
really
fine
actually
works
well
with
what
other
people
are
doing
in
this
space.
So
we
would
be
very
interested
in
in
making
sure
this.
This
is
all
well
coordinated.
B
Yeah,
I
I'm
all
up
for
coordination.
I
think
we
could
touch
base
once
this
session
is
over
and
we
could
discuss
that.
A
Okay
thanks
daniel
you're
next,
in
the
queue.
A
Sorry
shall
I
skip
ahead
and
just
get
harold
for
a
second.
I
think
you
were
just
going
to
ask
what
was
in
the
java
chat
right,
so
I
can
relay
it
for
you
with.
You
said
you
don't
understand
what
the
recipient
calendaring
system
should
do.
It
sees
the
conflicting
utc
offset
and
I
on
a
label.
B
B
Do
you
read
up
on
the
message,
but
let
me
just
give
me.
B
About
the
the
I
am
the
time
zones
changing
over
time,
if
I'm
correct.
B
I
see
yeah
the
the
utc
offset
is
a
is
supposed
to
be
the
source
of
truth
in
those
matters.
The
the
labels
and
any
additional
information
is
something
that
can
be
used
by
the
client
to
implementation.
B
You
could
say
to
you
to
process
additional
information
right
additional
context,
but
it's
not
necessary
to
take
those
into
account
and-
and
maybe
there'd
be
a
bunch
of
implementations
that
don't
even
care
about
them
right
if
they're
not
doing
any
localization
or
they're
not
dealing
directly
with
any
humans
if
they're
doing
timestamps
or
things
like
that,.
A
H
B
I
was
mostly
looking
for
an
extensible
way
to
generalize
this
format
without
having
to
write
down
as
part
of
the
rsc,
the
different
key
values
that
are
acceptable
and-
and
I
thought
it
would
be
really
hard
to
add
to
that
set
if,
if
one
had
to
do
a
new
rc
every
time.
So
that
was
the
mechanism
that
was
suggested
to
us
as
a
way
to
make
it
low
overhead
to
introduce
new
new
new
pieces
of
information.
B
But
I'd
be
happy
to
replace
that
with
something
which
is
maybe
of
a
lower
overhead
or
something
like
that.
A
Yeah
because
I'd
be
keen
to
kind
of
focus
on
the
dispatch
questions
here,
so
we
might
be
getting
just
a
bit
more
into
the
detail
of
the
the
work.
So
if
I'd
encourage
people
to
come
to
the
queue
we've
just
got
a
couple
minutes
left
on
the
agenda,
it's
very
packed
today,
so
I've.
I
can
see
some
java
chats
on
opinions
on
the
dispatch
questions.
So
how
do
we
move
ahead
with
this
work?
A
H
A
Okay,
thank
you,
john
you're.
Next,
in
the
queue.
I
Yeah,
I
I
partially
just
want
to
agree
with
what
harold
said,
because
I
didn't
know
he
was
going
to
say
it,
but
this
this
involves
enough
complexity,
that
it
it
likely
needs
a
working
group
and
to
add
one
piece,
one
more
piece
of
complexity
to
the
list
which
may
motivate
the
working
group
for
the
idea.
I
Further,
I'm
a
little
getting
a
little
worried
about
a
different
time,
synchronization
problem,
which
is
a
ietf
standard,
possibly
with
different
sets
of
definitions
and
name
spaces
and
an
ecma
standard
and
a
javascript
standard,
a
java
standard
and
and
an
iso
standard,
and
if
they
are,
if
they
are
all
different
or
even
several
of
them,
are
different.
I
B
Idea
is
for
us
in
ecmascript
to
to
put
this
to
to
try
to
get
this
into
ietf
in
whichever
way
is
most
acceptable
to
idea
folks
and
then
change
the
format
that
we
are
using
to
that
and
also
normatively
reference
that
its
standard,
so
that
we
don't
have
to
actually
maintain
this
ad
hoc
standard.
I
Well
that
that
that
sounds
like
a
perfectly
good
idea,
except
that
ecmas
script
is
not
the
international
standard.
The
iso
documents
is
the
international
standard
and
I'm
I'm
concerned,
as
I
said
in
the
chat
that
you're
not
coordinating
with
iso.
A
Yeah
sure
sorry,
I'm
gonna
cut
it
here,
because
we
do
have
a
really
full
thing.
Today,
I'm
seeing
people
posting
on
jabba
kind
of
a
general
agreement
that
a
working
group
is
what's
needed,
but
we'll
take
a
final
decision
on
the
list.
I'm
also
conscious
that
patrick's,
not
here
so
I'd,
be
keen
to
obviously
make
the
decision
with
my
co-chair
as
well.
So
we'll
just
say
thank
you
at
this
time
for
your
presentation,
we'll
take
it
to
the
list,
and
I
think
there
is
also
a
sort
of
mini
charter
for
this.
A
So
I'd
encourage
folks
to
head
over
to
the
list.
The
link
to
the
messages
is
in
the
agenda
and
just
kind
of
read
through
and
see.
If
that
seems
like
it,
a
buff
would
be
the
next
most
appropriate
step.
A
Okay,
so
our
next
presentation
is
from
karsten
take
it
away.
G
G
So
the
the
thank
you
so
the
the
question
that
is
coming
up
when
editing
documents
that
use
media
types
is
what
do
the
various
terms
that
we
are
using
actually
mean.
So
I
have
met
people
who,
when
I
talk
to
them
about
media
types,
tell
me
text
is
a
media
type.
Other
people
tell
me
text
plain,
is
a
media
type
and
the
other
group
of
people
is
telling
me
text.
Slash
plain
semicolon:
cassette
equals
utf-8
is
a
media
type.
G
G
We
also
have
it
in
the
term
of
actual
abn
f
that
describes
what
these
various
names
actually
mean.
So
it
would
be
nice
to
actually
consolidate
when
you
go
to
the
next
slide
to
to
actually
consolidate
the
terminology
we
are
using
in
this
space
and
also
the
abnf
that
we
are
using.
I
know
it
cannot
be
consolidated
perfectly
because,
of
course,
we
have
lots
of
of
existing
systems
that
are
slightly
subtly
different,
but
it
would
be
nice
to
just
have
something
that
can
be
referenced
from
new
documents
and
th.
G
This
observation
came
up
while
writing
a
draft
in
the
call,
a
working
group
where
it
would
have
been
nice
to
just
point
to
something.
But
there
are
ten
things
you
can
point
to,
and
not
none
of
them
actually
defines
all
the
things
that
that
are
needed,
and
there
are
lots
of
rfcs
that
that
use
these
terms
in
in
different
ways
as
well.
G
So
next
slide.
I
started
writing
a
little
document
that
actually
defines
some
terms,
so
that
makes
a
difference
between
a
media
type
and
a
media
type
name.
It
defines
another
term
called
content
type,
which
is
the
media
type
name
plus
parameters,
and
it
also
addresses
some
things
that
are
probably
more
specific
to
core.
G
Like
content,
format,
numbers
and
content
format,
strings
which
are
content
types
combined
with
a
content
coding,
we
like
to
give
these
things
numbers
so
11050,
for
instance,
this
application
slash
json
in
deflate
content,
coding
next
slide
so
yeah.
I
I
wrote
that
draft
thinking
that
we
could
simply
decide
this
in
the
car
working
group.
G
But
then,
of
course,
we
we
are
writing
a
specification
that
tries
to
define
terms
that
that
touch
just
about
everything
that
is
in
the
application
area,
applications
and
real-time
area
of
the
iatf,
and
and
probably
things
beyond
that.
So
I
I
was
reminded
that
core
is
not
really
chartered
for
this
kind
of
work
and
also
that
this
work
would
probably
benefit
from
broader
discussion
and
and
consensus.
G
G
So
I'm
I'm
calling
on
on
the
wisdom
of
the
the
crowd
of
this
working
group
here,
I'm
I'm
generally
looking
for
for
advice
how
to
get
a
document
like
this,
both
written
but
more
importantly,
agreed
between
the
various
groups
that
that
actually
are
using
media
types
and
and
related
concepts
like
content,
types
and
content
performance.
A
Thank
you.
Thanks
for
the
presentation,
okay,
so
I'll
open
up
the
queue
I
can
see,
we've
already
got
mark
nottingham
in
the
queue
ask
away.
A
J
Lovely
okay,
hi
karsten,
so
I
think
the
the
my
first
blush
reaction
to
this
is
that
aligning
the
terminology
is
a
wonderful
thing
to
embark
upon.
The
terminology
in
this
area
has
always
bugged
me
it's
imprecise
and
massively
confusing
to
people
who
are
new
to
this.
J
So
I
don't
see
the
value
and
I
see
a
lot
of
risk
in
aligning
at
that
layer.
So
if
you
restricted
this
to
the
the
terminology,
I'd
be
very
excited
beyond
that.
I'm
concerned,
and
especially
since
we
have
just
finished
work
group
last
call
on
http
core
the
opportunity
for
adjusting
things
like
a
b
and
f
in
http
is
probably
past.
J
I
I
think
the
terminology
is
safe
to
do
because
at
first
glance
I'm
sure
julian
will
at
some
point
correct
me.
I
don't
think
we
talk
deeply
about
things
like
media
types
and
media
subtypes
and
use
that
kind
of
terminology
in
http
itself.
That's
usually
for
applications
who
use
http.
You
need
to
use
that
kind
of
terminology.
G
G
The
way
it
is
male
is
going
to
stay
the
way
it
is
and
so
on,
but
it
would
still
be
useful
to
have
a
document
that
that
can
be
referenced
in
case
you
don't
have
any
specific
tie-ins
to
those
existing
ecosystems
and
if,
if
you
think
this
should
be
done
in
call
that
that
would
be
fine
with
me,
we
we
just
need
this,
and
of
course
we
could
do
it
in
the
documents
that
actually
use
it.
But
I
think
doing
the
the
abn
f
separately
in
a
separate
document
has
a
better
reuse
value.
J
Sorry,
I
had
to
click
more
buttons.
I
I
think
that
that
that's
reasonable,
although
I
think
in
the
same
way
that
we
ask
people
when
they
define
new
http
methods
to
put
them
in
separate
documents.
So
they
don't
look
like
they're
application.
Specific
I'd.
Ask
you
to
break
the
terminology
out
to
a
separate
document,
because
that
is,
I
think,
more
universal
and
and
more
referenceable.
And
if
you
lump
it
in
with
the
abnf,
people
are
going
to
get
confused
about
their
relationship.
G
A
You
thank
you
pete
you're.
Next,
in
the
queue.
G
F
Sure
yeah,
but
I
mean
media
type,
top
level.
Media
type
subtypes
are
all
in
there.
It
sounds
like
you,
you
want
to
add
on
to
this,
which
is
fine.
I
guess,
but
let's
be
clear
about
what
pieces
you
actually
need
to
add
and
not
invent
new
stuff.
K
F
A
Okay,
thank
you
colin
you're,.
L
Okay,
so
I
I
think
it's
unclear
how
much
what
you
want
to
do
here
is
clarify
terminology
and
how
much
what
you
want
to
do
is
extend
this
mechanism
to
something
much
more
than
it
currently
is,
and
both
of
those
seem
like
reasonable
things
to
discuss.
But
when
I
read
the
documents,
I
don't,
I
think,
actually
the
core
documents
that
define
this
stuff,
which
are
not
the
ones
you
reference
are
the
ones
like
define.
L
The
iana
registry
are
pretty
crisp,
so
I
I
think
that
you
need
to
show
there
actually
is
a
terminology
problem
and
get
a
little
bit
more
down
on
that,
and
what
needs
to
be
clarified
in
the
terminology
is
one
thing
and
then
separate
out
the
parts
of
the
extensions
now
the
extension
parts.
I
know
that
a
lot
of
this
we've
done
as
bcps
in
the
past
in
an
apps
area
working
group-
I
you
know,
I
don't
see
a
problem
with
that.
L
L
I'd
like
to
see
a
crisp
separation
of
what's
wrong
with
our
current
terminology
and
let's
update
those
bcps
that
did
those
terminologies
that
were
could
probably
be
done.
Much
the
same
way
that
bcps
were
as
one
thing
and
that's
purely
a
terminology
thing,
and
then
the
second
thing
would
be
extensions
and
if
we're
doing
extensions,
then
then
we
should
be
very
close
where
why
what
the
scope
and
who
uses
them,
what
other
things
have
to
support
them?
L
L
L
G
G
L
I
seemed
hard
to
figure
out
exactly
what
was
being
proposed
from
the
current
draft.
That's
all
and
I'm
not
saying
that
if
they
were
carefully
like,
if
those
were,
I
mean,
I
don't
think
anyone
has
a
problem
with
us
clarifying
some
of
our
terminology,
particularly
where
we
get
it
confused
between
multiple
rfcs
over
the
years.
Okay,
that's
that's
a
no-brainer
and
sometimes
defining
a
term
for
something
that's
always
existed,
but
we
didn't
have
a
good
word
for
it
and
we
were
sort
of
using
things
like
well.
L
You
know
the
string
plus
this
string,
that
comes
after
it,
that's
a
good
thing
too,
but
I
think
that's
very
different
than
creating
something
that
provides
further
bits
of
information
that
transfer
over
the
wire
that
change
what
you
can
do
with
these
things,
which
again,
I
think,
is
probably
a
good
thing
to
do.
I'm
not
arguing
against
that,
but
those
are
two
very
different
things
and,
and
one
and
there's
there's
not
the
second
one
is
not
just
an
update
to
terminology.
A
Thank
you.
I
can
see
discussion
in
jabba
someone
suggesting
that
a
short-lived
working
group
might
be
the
best
kind
of
solution
to
this.
I'd,
encourage
people
to
join
the
queue
and
give
a
view
on
the
dispatch
question
what's
needed
for
next
steps
to
progress
this
work,
so
I
can
see
no
one
else
in
the
queue,
but
we've
had
so
far.
A
Someone
suggested
it
should
be
p,
I
think
suggested
as
ada
sponsored
or
individual
submission
and
cullen
saying
to
go
away
and
kind
of
really
focus
on
the
scope
and
what's
included,
and
then
some
chat
about
a
short-lived
working
group.
So
anyone
with
a
final
view
on
this
please
come
up.
We
have
the
discussion
time.
Let's
use.
A
I
Since
you,
since
you've
decided,
you
have
extra
time
colin
said
almost
everything
I
was
going
to
say,
but
let
me
add
to
the
comment
about
a
a
special
short-lived
working
group
this
this.
This
is
dangerous
to
do
in
a
in
a
working
group
or
or
even
an
a.d
sponsored
document
that
that
doesn't
have
a
a
specific
charter
and
and
openness
to
broad
participation.
I
People
who,
who
involved
in
this
from
from
the
standpoint
of
other
work,
may
not
want
to
get
involved
with
core.
I
agree
that
including
the
existing
document,
it's
hard
to
tell
what
the
goals
and
constraints
are
and,
and
that
points
fairly
clearly,
in
my
mind,
to
it
to
a
to
a
wg,
even
a
very
short-lived
one.
Thanks.
A
A
I
can
see
on
the
chat
says
in
new
working
group.
It's
overkill
for
this
simple
document
and
harold
you've
just
joined
the
queue.
H
G
A
I
think
the
general
decision
we're
coming
to
you
here
is
that
some
sort
of
questions
about
scope
and
the
more
a
more
clear
problem
statement
would
be
helpful
and
then
to
revisit
this.
So
we
can
understand
exactly
what
the
work
is
that
you're
trying
to
do,
and
so
whether
it
needs
a
working
group
or
if
the
document
is
a
bit
more
simple.
But
I
think
there
is
general
agreement
that
the
work
is
useful.
A
That
we'd
like
to
see
the
work,
progress
but
just
needs
a
more
clear
problem
statement,
and
then
we
can
discuss
a
kind
of
working
group
or
have
a
look
on
how
simple
the
document
would
be
and
then
whether
it
could
be
a
d
sponsored
instead.
A
A
So
thank
you
very
much
for
the
presentation,
carsten
and
for
addition,
everyone,
okay,
so
we
next
have
reuben
or
lars
to
talk
about
http
content,
renegotiation.
M
Hi
this
is
reuben,
so
I
know
the
word.
Negotiation
is
on
the
slide,
but
let's
not
get
distracted
by
that.
If
you
follow
the
link,
the
actual
proposal
we
have
is
as
follows.
So
a
many
apis
on
the
web,
if
not
most
apis,
are
actually
lying
when
they
communicate,
they
will
tell
you
that
they're
serving
you
json
or
xml,
there's
only
a
minority
of
apis.
That
will
tell
you
actually
I'm
using
this
very
specific
kind
of
json,
for
instance
like
very
specific
media
types,
but
most
apis
out.
M
If
you
will
that
they
can
that
they
can
adhere
to
so
the
issue
is
that
today
you
either
have
apis
under
specified
representation.
By
saying
this
is
json
or
you
almost
have
to
like
overspecify,
be
very
specific
what
it
is,
but
then
you
kind
of
lose
the
fact
that
it
is
json
and
can
be
used
in
different
context.
So
what
we've
done
is
we're
proposing
we're
proposing
a
document
here
in
which
we
want
to
help
with
a
couple
of
things
for
to
be
specific.
M
On
one
hand,
we
want
to
help
servers
indicate
what
kind
of
extra
constraints
the
representation
conforms
to
on
top
of
json,
xml
and
so
on.
We
want
clients
seconds
to
be
able
to
discover
what
kind
of
options
exist
on
the
server
side,
what
kind
of
phrase
constraints
that
are
supported,
then
we
want
clients
also
to
be
able
to
to
to
request
specific
versions
like
hey.
M
To
do
so,
we
reuse
the
notion
of
profiles,
which
is
an
existing
rfc
in
which,
indeed,
you
can
say
well,
this
is
json
plus
these
and
these
and
these
extra
constraints.
However,
I
look
at
profiles
a
couple
of
bits
of
glue
if
you
will
what
we're
missing
to
make
it
all
work
together,
like
indicating
friends
if
multiple
profiles
are
supported
in
a
representation
clients
asking
for
specific
representations
and
also
clients
indicating
that
their
representation
conforms
to
some
things.
M
All
these
things
were
not
fully
glued
together,
so
the
draft
that
we're
currently
proposing
glues
these
together
using
existing
mechanisms
such
as
profiles,
link,
hints
and
so
on.
The
only
new
thing
we're
really
introducing
here
is
also
a
header
such
that
we
can
have
the
reactive
content
negotiation
from
the
server
side.
So
just
as
you
know,
regular
negotiation,
that's
only
just
a
small
part
of
the
proposal.
Really.
What
this
is
ultimately
is
about
is
how
do
we
deal
with
the
fact
that
many
content
times
today
are
underspecified?
M
M
It
is
adding
and
gluing
up
profiles
for
media
types
such
that
servers
can
keep
on
communicating
in
json,
xml
and
so
on
already
today,
but
all
of
the
assumptions
that
clients
are
making
today
and
which
break
as
apis
evolve
to
make
those
explicits
in
a
reusable
mechanism,
that's
orthogonal
to
the
rest
of
the
whole
stack.
M
So
that
was
a
very
short
my
proposal,
there's
a
link
on
the
slants
to
the
full
version,
which
I
will
also
add
in
chat
for
your
convenience
and
I'm
happy
to
hear
what
you
think
about
it.
Specifically
what
right
places
within
ietf
to
have
these
kind
of
discussions.
What
do
you
think
is
useful
and
what
you
need
from
input
from
our
site
to
make
this
happen?
So
thanks
advance
for
considering.
A
A
A
J
J
It
seems
like
this
is
potentially
generic
negotiation
mechanism,
and
so
that
causes
a
question
whether
it
could
be
used
by
their
folks.
So
to
be
good,
I
thought
it'd
be
good
to
get
in
front
of
a
broader
audience
than
just
the
hbi
api
folks,
and
I'm
also,
I
guess
just
wondering
I
mean
this
mechanism-
is
something
that
looks
good
on
paper,
I'm
just
wondering
if
there
are,
or
or
at
least
feasible
on
paper,
I'm
wondering
if
there
are
api
practitioners
and
implementers
who
want
to
be
able
to
do
this.
J
You
know
if
they're
running
up
and
saying
we
tried
to
use
media
types.
We
tried
to
use
the
structured
suffixes
on
media
types
and
it
wasn't
descriptive
enough
for
what
we
need
to
do
in
our
api.
And,
if
that's
the
case,
then
then
that's
something
that
would
be
worth
pursuing.
K
All
right
so
yeah,
the
question
is
well
put:
does
this
work
outside
of
http
apis
and
I
will
say
that
my
first
thought
on
reading
this
was
a
potential
applicability
in
things
like
indicating
whether
a
c
a
given
seabor
client
understands
packed
sibor
or
if
it
needs,
you
know,
unpacked
sebor
and
there
there
are
a
number
of
situations
where
it's
not
just
the
format,
but
also
what
extensions
do
I
support
and
that,
and
so
I
I
do
think
there
is
some
applicability
here,
but
there
and
also
why
dragons
so
there's
real
work
to
be
done
here.
A
Okay,
thank
you,
timothy,
hampton
you're.
Next.
N
Oh
weird:
that's.
A
D
N
Think
it's
it's
an
odd.
I
think
it's
a
risk
that
the
the
hereby
dragons
think
really
kicks
in
and
that
so
I
I'd
be
keen
to
see
a
kind
of
strong
restriction
on
the
scope,
maybe
to
try
and
keep
it
out
of
semantics
and
and
keep
it
talking
about
formats.
N
You
see
what
I
mean
see
the
distinction
so
yeah
it
bothers
me.
N
A
Okay,
thank
you.
Rich
you're,.
A
C
You,
okay,
so
so
co-chair
of
the
http
api
group,
as
mark
had
said
we're
just
trying
to
figure
out
what's
doing
what
we're
doing
and
getting
a
community
going,
it
could
end
up
in
http
api,
but
I
would
rather
it
didn't
start
right
now
start
right
away.
C
A
Thanks
rich
and
you
can
see,
we've
got
patrick
joining
us
now
as
well,
so
no
longer
going
solo,
patrick,
I
don't
know
if
you
want
to
say
hi
or
put
you
on
the
spot.
A
Okay,
so
I'm
not
hearing
any
clear
signals
for
whether
we
want
this
to
go
to
api
or
biz
might
be
a
good
idea
to
just
continue
the
discussion
on
list
and
try
to
find
a
natural
home.
A
M
I'm
very
sorry,
chris.
I
don't
find
the
cue
mechanism
there
probably
something
wrong
and
I
just
want
to
confirm.
The
point
has
been
said
like
we
also
see
it
as
wider
than
apis.
I've
pitched
it
from
an
api
perspective
now
for
making
the
story
understandable,
but
this
is
a
need,
a
much
more
generic
mechanism
as
far
as
we're
concerned
as
well.
So
just
to
add
to
that.
A
Okay,
thank
you
for
the
time
and
yeah
we'll
we'll
continue
on
list
and
just
for
the
rest
of
the
session.
If
you
want
to
join
the
queue,
you
just
tap
the
hand
icon,
okay,
so
we're
moving
into
the
kind
of
art
section
of
the
agenda
now,
so
we
just
highlight
as
always,
a
few
meetings
of
interest.
So
there's
a
new
buff
this
week
on
a
danish
day
in
authentication
for
iot
service
hardening.
That's
it
friday
at
12
o'clock,
utc,
so
we'll
see
modulate
for
your
time
zone.
A
And
then
there
are
a
couple
of
not
new
but
newish
art
working
groups,
so
rtc
web
has
recharted
and
wish
has
been
charted
and
s
frame
is
kind
of
new
as
well.
So
we
just
highlight
those
for
you
and
in
other
exciting
news,
cluster
238
has
cleared
so
let
the
party
rain.
A
A
Utc
again
so
the
rsc
editor
future
development
program
and
shmu
staying
at
home
and
as
we
are
right
now,
meeting
only
online
and
that
work
continues
and
then
a
couple
of
other
dispatchy
groups
that
we
always
highlight:
there's
gen
dispatch,
so
dispatch
for
the
general
area
and
security
dispatch,
sec
dispatch
for
the
security
area
and,
finally,
the
iab
open
meeting,
which
is
a
newish
one
and
so
also
worth
having
a
look.
Patrick.
I
don't
know
if
you
want
to
say
anything
at
this
point,
we're
just
kind
of
recognized
during
the
meeting.
O
I
really
appreciate
you
setting
all
this
up,
so
this
terrific,
I
will
mostly
listen
if
I
can
help
out
with
the
queue
as
we
go
I'm
happy
to,
but
this
is
great
thanks.
Chris
christie,
no.
A
Worries
cool.
Thank
you!
Okay,
so
we
just
move
into
the
kind
of
art
area
section.
So
all
of
these
presentations
are
just
kind
of
like
fyis,
for
your
information
and
to
raise
awareness
of
the
technology
topics
we're
not
taking
dispatching
decisions
on
these.
It's
just
an
opportunity
to
air
out
the
technologies
and
get
some
interested
folks
together
and
then
follow
up
with
the
presenters
or
the
authors
of
the
draft
after
the
after
the
session.
So
first
up
we
have
apn
application.
P
Hello
kirsty,
can
you
hear
me.
P
Okay,
okay,
thank
you.
In
fact,
the
shooting
now
is.
This
is
the
champion
from
huawei.
In
fact,
the
shooting
now
is
in
the
spring
working
group.
I
will
do
the
presentation.
P
Okay,
my
this
is
my
first
presentation
in
the
in
the
art
area,
because
I'm
I'm
always
working
in
the
routine
area,
but
because
of
the
application
awareness
working
work
proposal,
much
confusing
in
the
ietf.
So
I
would
like
to
do
the
clarification
in
the
application
area.
Okay,
next
page.
P
Okay
purpose
of
the
presenting
in
this
working
group,
so
in
fact
we
have
the
discussion
in
the
apm
mailing
list
regarding
the
scope
of
the
apm
work.
The
api
is,
the
application
are
networking.
Apn
is
the
abbreviation
of
the
application.
We
are
networking.
P
In
fact,
we
want
a
constraint
of
the
scope
of
apn
to
only
focus
on
the
network
side
solution,
that
is,
the
application.
Identifier
is
derived
as
a
network
edge
instead
of
the
host
or
the
application.
P
So
that
means,
if
we
do
like
this
way.
So
this
is
the
network
aside.
The
problems
instead
of
instead
of,
is
as
a
application
problem
regarding
the
application
area.
P
So
here
we
would
like
to
introduce
the
concept,
clarification,
the
scope
and
also
hope
this.
The
people
in
the
art
area
can
understanding
the
work
well.
So
if
you
have
interest
in
this
work,
you
can
also
join
this.
The
ep
mini
list.
We
can
have
more
across
the
area
communication
for
better
understanding
each
other.
Okay,
next
slides.
P
Okay,
so
here
we
will
introduce
this.
The
apn,
so
apn
is
focused
on
the
a
framework
and
a
set
of
mechanism
to
derive,
convey
and
use
attribute
information
to
allow
the
implementation
of
the
fine,
greener
user
group
or
the
application
group
and
the
service
level
requirement
as
a
network
layer.
P
That
means
the
network
does
not
need
to
know
which
application
are
sending
the
traffic,
because
the
network,
as
a
network
edge,
is
just
to
learn
this.
The
application
group,
so
that's
used
for
the
classification
and
also
because
of
this
telling
the
network
which
application
are
running,
would
also
propose.
This
is
the
priority
issue.
This
is
not
the
scope
of
this,
the
apn
christie.
It
seems
the
tread
in
the
queue,
so
I
will
go
on
or
tell
you
we'll
propose
this
your
question.
Firstly,.
O
I
think
you
can
proceed
with
the
presentation
and
we'll
take
questions
at
the
end
ted,
if
that,
if
you're
trying
to
clarify
something,
feel
free
to
jump
in
directly,
okay.
P
Okay,
so
the
apn
is
about
telling
the
network
what
policy
to
apply
the
traffic.
That
means
the
application
can
apply.
Multiple
policy
to
different
traffic
flows
and
also
the
multi
applications
can
ask
for
the
same
policies.
So
this
this
is.
The
policy
process
means
that
we
need
an
author
to
for
the
network
to
learn
the
specific
application
information,
but
it
is
just
needed
to
a
classification
as
a
network
edge
so
and
also
in
history.
P
There
are
a
lot
of
similar
work
that
caused
the
confusion
such
as
power
g
and
sabbath
plus
or
the
network
token.
It
has
been
discussed
in
the
application
area
or
the
transport
area,
but
in
fact
the
apn
is
different
from
this.
The
this
works
first
for
the
sabad
plus
and
the
network
token.
It
focuses
on
to
encapsulate
the
application
information
in
the
host
and
the
application.
P
P
P
When
mapping
the
wine
line
into
the
operators
network,
there
are
usually
multiple
network
paths
with
different
sr
guarantees
available
between
the
two
endpoints
of
the
tunnel.
Connecting
the
cpu
nodes,
in
fact
in
the
mef,
is
already
defended.
This
is
the
standards
related
with
the
sd1
either
car,
as
this
is
the
cpe.
P
P
According
to
this,
the
application
group
information
and
the
user
group
information
to
severely
into
corresponding
paths
to
satisfy
the
sra
requirements
and
also
in
the
along
this,
the
past
in
the
one
network,
it
can
collect
the
corresponding
the
performance
environment,
data
for
the
specific
application
group
or
the
user
group,
and
also
because
of
the
service
training
process
and
also
in
the
one
network.
It
also
uses
the
application
group
information
and
also
this
is
the
user
group
information
for
specific
service
function
process.
P
Okay,
so
I
know
here
this
is
the
take.
This
is
the
usual
propose
these
issues
and
the
possible
solutions.
In
fact,
I
already
explained
these
solutions
in
the
pre-war
slides.
In
fact,
there
have
been
some
these
alternative
solutions.
P
For
example,
some
of
the
solutions
proposed
in
order
to
facilitate
the
underlying
one
one
network
to
for
the
policy
process,
so
it
can
encapsulate
various
policies
in
at
least
trv
in
the
head
of
each
packet
when
the
packet
into
the
one
network
it
can
for
the
you
can
use
this
the
list
of
the
tre
for
the
policy
process,
but
we
know
that
when
you,
this
is
the
method
all
you.
This
is
the
five
tubes
in
the
ip
package.
P
This
proposes
the
challenges,
because
this
is
the
five
tube
information
in
the
payload,
but
when
you
encapsulate
this
the
tunnel,
so
that's
the
nodes
along
this
one
network
cannot
be
aware
of
this.
Be
aware
of
this,
the
group
information
so
and
also
with
this
ipsec.
It
has
also
impossible
to
abstain.
This
the
transpo.
This
is
the
transport
layer,
information
and
also
in
the
ipv6
the
data
plane.
P
Now,
as
this,
the
ipv6
external
header
has
been
widely
used
so
because
of
this
information,
this
is
a
transport
layer,
information
for
the
fab
tube,
like
this,
the
port
number
it
will
beneath
this
the
ipv6
extension
header.
It
will
more
difficult
for
the
network
node
to
learn
this.
The
information,
okay,
next
slides.
P
Okay,
next
page,
okay,
so
here
are
these
user
to
solve.
This
is
the
issue
so
that
we
can
acquire
and
construct
attribute
as
a
network
edge
and
encapsulate
it
in
the
package,
so
that
such
information
can
be
treated
as
an
object
in
the
network.
P
This
can
bring
some
this
the
benefits
so
because
this
you,
this
is
the
one
field,
the
information
instead
of
the
five
tube
information,
so
this
is
the
so
this
can
improve
this
the
scalability
and
also
you
this
information.
It
can
provide
a
very
flexible
policy
info
enforcement
in
various
nodes
and
the
service
function,
along
with
the
network
paths.
P
Furthermore,
with
this
such
information,
a
module
service
could
be
enabled,
for
example,
so
let's
use
the
policy
executive
execution
on
the
service
function.
Changing
can
be
based
on
this.
The
application
attributes
instead
of
this,
the
five
tube
information-
and
we
can
also
implement
this,
the
more
fine
granularly,
ready
performance
environment
and
also
this
is
the
for
the
sd1,
so
this
underlay
performance
guarantee
can
be
achieved.
P
Slides,
okay,
so
in
fact
so
this
because
this
is
a
specific
issue
for
the
limited
network
domain
in
the
rooting
area.
In
fact,
in
the
past
years
there
are
the
a
lot
of
these
solutions
and
has
been
proposed
and
been
adopted.
P
So
the
first
we
say
that
the
dlcd,
so
that's
the
use
for
the
div
cell,
but
the
fields
is
not
big
enough,
because
this
is
the
for
the
more
fine
granularity
and
also
in
the
for
the
ipv6
there's
the
ipv6
flow
label
to
identify
the
different
flow
and
also
use
the
npr's
entropy
label
to
identify
this
the
flow
label.
But
this
is
the
because
this
always
has
hazard
defender
for
the
specific
other
usage,
so
that
you
cannot
use
the
for
the
for
the
identify,
the
application
attributes
and
also
there's
the
service
chaining.
P
P
O
I
apologize
for
jumping
in
I
just
we're
going
to
okay,
second
time
we're
down
to
four
minutes,
so
I
just
want
to
give
you
a
time
to
make
sure
we
can
get
at
least
a
couple
of
questions,
and
so
perhaps
a
summaries
in
order
here.
P
P
P
Okay,
so
now
that's
this
is
the
last
page,
and
also
this
is
the
question
student
to
be
addressed.
So
here
this
is
the
secularity
issue.
We
wanted
to
learn
this,
the
more
information
about
this,
the
secularity
issue
and
for
the
privacy
issue.
We
propose
this,
the
idea
and
the
concept
to
mitigate
this
issue,
because
this
is
just
use
this
user
group
of
application
group
instead
of
this
specific
applications
and
also
use
this
information
as
opaque
value.
P
So
and
also
this
is
just
the
introduction
of
the
apn
for
this,
the
other
area.
We
would
like
to
clarify
this
scope,
and
also-
and
because
we
so
this
user
has
noted
directly
with
this
other
area,
but
we
would
like
to
learn
in
the
other
layer
about
this
development
trend
of
the
new
application,
so
that,
according
to
this,
we
it's
better
for
us
to
summarize
this.
The
requirement
of
this,
the
new
applications
for
to
classify
these
applications
in
the
different
group.
So
this
is
my.
P
Patrick,
in
fact
I
I
would
like
to
say
that,
because
the
last
pages
just
introduce
our
progress,
I
would
like
to
stay
in
the
previous
page.
I
would
like
to
learn
the
opinion
of
the
experts
in
the
other
area.
Okay,.
O
In
we're
in
the
art
area
section
of
the
agenda,
so
our
intention
at
least
today
is
not
to
dispatch
any
of
this
work,
and
with
that,
should
we
open
for
a
couple
questions.
Does
that
make
sense.
P
Okay,
patrick
before
that
one,
can
you
go
to
the
page
return.
Q
Hi
john
bin,
thanks
for
your
presentation
today,
a
couple
of
points
to
clarify
it
sounds
like
to
kind
of
work
backwards
that
you
don't
currently
have
a
specific
application.
That's
asking
for
this
functionality
instead
you're
coming
to
this
group
to
ask
if
there
are
applications
which
would
use
this
functionality.
Is
that
correct.
P
In
fact,
for
for
me,
I
also
I
trusted
to
for
the
purpose
you
just
clarify.
This
is
the
scope.
That's
this.
We
just
used
as
the
classification
of
this
the
applicant
group,
and
also
this
is
encapsulated
in
the
network
nodes.
Instead
of
use
that
also
to
be
encapsulated
in
the
host
of
the
application.
Q
Yeah,
the
other
point
I
wanted
to
to
make
was
what
I
saw
as
a
bit
of
a
confusion
between
slide
three
and
slide
four.
Q
So
if
you
could
go
to
slide
three
for
a
moment,
so
in
slide
three
you
you
mentioned
that
this
was
something
which
could
possibly
lose
actually
slide
two,
but
let's
go
on
to
slide
four
yeah
user
group,
application,
group
and
service
level
requirements,
and
yet
on
slide
four,
if
we
go
on
to
that,
it
seems
like
at
least
one
of
the
implementations
of
this
would
be
a
network
edge
device,
that's
doing
inspection.
P
Okay,
this
is
a
good
question
ted,
so
here
this
in
fact
for
earth
for
the
carrier
specific.
This
is
the
domain,
the
first
one.
I
think
that
we
can,
according
to
this,
the
five
tube
information
in
the
packet
for
the
application
group
or
the
user
group,
so
this
user
just
use
the
one.
P
This
is
the
possible
method
and
the
second
one,
because
you
know
that
specific
user
is
expect,
especially
for
the
fixed
accessed
user
or
the
wireless
access
user,
because
it's
always
the
first
to
communicate
with
the
communicator
with
the
network
for
the
authority.
Oh
sorry,
the
vision
for
this,
the
user.
So
that's
the
way
it
asks
for
the
authority
authorization
so
that
the
user
can
get
this
the
user
id.
So
that's
in
the
fixed
access,
the
network
or
in
the
wireless
network.
P
You
can
use
this
the
vla
id
to
identify
this
user
or
for
this
the
course
this
is
the
surface
group
such
as
this,
the
multicast-
or
this
is
the
unicost.
So
that's
a
in
order
for
the
final
granularity,
so
this
is
combined.
This
is
the
five
tube
information,
and
also
this
is
the
other.
This
is
the
user,
or
this
is
the
service
identification
information
so
that
we
can
create
this.
The
user
group
information-
all
this
is
the
application
group
information
that
would
be
more
fine
granularity
than
the
five
tube
of
this
package.
A
Thank
you,
hi
we're
gonna
have
to
cut
the
discussion
here
and
we've
got
a
very
full
agenda.
So
thanks
for
the
presentation
and
we'll
just
take
discussion
to
the
list,
I
see
a
lot
of
questions
in
jabber
as
well
still
to
go
through.
So
thank
you.
Okay,
so
robin
you're
up
next
to
speak
about
q
log.
R
Which
stands
for
quick
logging
and
this
project
started
about
two
years
ago,
and
we
noticed
that
new,
quick
and
hp3
protocols
were
becoming
a
bit
complex
and
we
would
need
some
advanced
tooling
to
debug
and
analyze
them.
What
you
would
normally
do
next
slide
for
something
like
tcp
is,
you
would
do
a
packet
capture
somewhere
in
the
network
and
they
would
use
tools
like
wireshark
to
analyze.
R
What's
going
on
for
quick,
you
can,
of
course
still
do
that,
but
it's
more
difficult
next
slide,
because
quick
encrypts,
almost
all
of
its
transport
level,
metadata
as
well.
So
to
do
this,
you
would
have
to
have
an
entire
packet
capture
with
the
backup
payload
also
there,
and
also
the
tls
decryption
secrets,
which
can
lead
you
into
some
trouble
in
large
scale
deployments
through
scalability
and
privacy.
This
is
also
something
that
we've
already
seen
for
encrypted
application
layer
protocols,
of
course,
which
are
also
difficult
to
analyze
using
just
wireshark.
R
There's
a
second
problem
here,
also
long
running,
which
is
next
slide,
which
is
that
not
all
aspects
of
the
protocol
are,
of
course
sent
over
the
wire.
The
typical
thing
in
quick
was
the
congest
control
information,
which
is,
of
course,
not
synced,
and
so
the
approach
that
we
proposed
for
a
quick
next
slide
was
to
instead
of
doing
things
at
network
level.
R
R
Most
implementations
have
some
form
of
debug
logging
or
output
available,
but
the
idea
for
qlog
was
to
have
a
single
format
single
schema
that
all
the
different
implementations
would
all
follow,
which
would
make
it
much
easier
to
write,
reusable
tooling
and
to
share
data,
and
so
qlog
is
really
quite
simple.
Next
slide,
at
least
for
now
we're
just
using
a
very
straightforward,
json,
serialization
defining,
for
example.
R
If
you
want
to
log,
if
you
receive
a
packet
which
fields
you
should
log
in
where
they
should
be
very
similar
for,
for
example,
the
congestion
control
related
events,
as
you
can
see
on
the
right
using
nqlog
as
an
input
for
tools.
Next
slide,
we've
also
built
quite
a
few
quicken
hp3
tools
and
what
is
called
the
qvis
tool
suite
giving
you
things
like
this:
the
sequence
diagram
showing
the
packets
going
over
the
wire
and
also
how
they
change
the
internal
endpoint
state
and
next
slide.
R
This
approach
of
having
both
the
format
and
some
reusable
tooling
has
turned
out
quite
interesting
for
quick,
leading
to
the
majority
of
the
implementation
supporting
the
format.
One
of
the
main
ones
is
facebook.
We're
actually
deploying
this
at
scale
to
analyze
their
hb3
deployment,
and
that
seems
to
be
working
quite
well,
and
so
because
of
this,
the
fact
that
it
seems
to
be
worth
the
effort.
This
has
so
far
been
two
individual
drafts
next
slide.
R
We
are
now
looking
to
adopt
the
dose
within
the
quick
working
group
as
part
of
the
upcoming
recharger
over
the
coming
months,
one
of
the
main
goals.
There
is,
of
course,
to
finalize
all
of
this
for
quicken
http
3.,
but
the
secondary
goal
is
to
look
if
we
can
actually
generalize
this
to
more
protocols.
Of
course,
that
is.
R
That
is
one
of
the
main
reasons
that
I'm
here
today
to
make
sure
more
people
are
aware
of
that,
because
it
might
impact
some
of
you
down
the
line,
because
the
whole
idea
of
q
log
is
again
quite
simple.
It's
just
logging
things
in
a
standard
way
inside
of
the
implementations
directly,
which
can
of
course
be
useful
for
other
things.
R
I've
listed
here
a
couple
of
projects
where
people
are
concretely
working
on
them,
or
at
least
thinking
about
using
a
similar
approach,
and
I
wanted
to
highlight
that
it's
not
just
even
the
protocols
themselves,
but
also
some
higher
level
logic
as
well.
There
is
one
project
looking
at
adding,
for
example,
adaptive
bitrate
algorithm
decisions
into
the
same
logs
as
where
you
have
the
quick
layer,
just
control
information,
hopefully
making
it
easier
to
correlate
and
debug
these
complex
interactions.
R
As
we'll
see,
there
are
two
different
drafts:
one
deals
with
the
quicken
http
3
event
specifically,
but
the
other
one
is
called
the
main
schema
and
that
kind
of
includes
all
of
the
protocol
agnostic
stuff
that
we
might
need-
and
the
hope
is
that,
eventually
this
will
turn
into
let's
say
a
framework
or
a
set
of
guidelines
and
best
practices
that
you
can
use
to
define
new
q
log
schemas
for
different
protocols
down
the
line.
R
Of
course
doing
that
comes
with
plenty
of
challenges.
It's
not
going
to
be
as
straightforward
as
I
as
I
would
like,
and
I
wanted
to
highlight
three
of
these,
the
top
three
ones.
Just
to
give
you
an
idea
of
the
type
of
discussion
that
we
will
probably
have
next
slide.
R
So
the
first
one
is
what
the
event
definitions
should
actually
look
like.
A
very
straightforward
thing
to
do
is
just
map
the
wire
image
wire
serialization,
as
we
see
fit
into,
for
example,
json,
which
is
what
you
see
here,
for
example.
Here
we
have
an
acknowledgement.
Oh
no
sorry
here
we
have
an
acknowledgement
frame
on
the
left
that
is
missing
the
acknowledgements
for
packet
number
16.,
which
doesn't
immediately
mean
that
the
implementation
also
marks
packet,
number
16
as
lost.
This
typically
takes
a
few
negative
acknowledgements,
so
what
you
need
is
what
is
now
shown
on.
R
There
it's
something
very
loose
that
is
not
well
defined,
and
so
we
would
prefer
to
switch
this
to
something
more
well
defined,
which
I
know
is
present
at
the
ietf.
I
just
don't
have
enough
experience,
choosing
the
correct
one
in
hopes
that
we
can
automatically
generate
serializers
and
these
serializers
for
these
formats
in
different
programming
languages
and
contexts.
R
R
Finally,
a
very
big
challenge,
I
think,
is
privacy,
as
we
said
conceptually.
Of
course,
it's
very
easy
to
leave
out
privacy,
sensitive
information
at
the
endpoints.
However,
in
some
debugging
use
cases
you
of
course
still
need
those
ip
addresses
or
those
urls
that
you're
going
to
be
logging.
So
the
current
approach
proposed
approach
is
to
use
different
sanitization
levels
going
from
relatively
loose
to
very
strict,
defining
which
fields
should
you
can't
include
or
how
they
should
be
encoded
or
or
or
hashed,
that
kind
of
stuff.
R
In
summary,
what
I
hope
and
think
will
eventually
maybe
happen
is
that
we
would
have
a
separate
q
log
working
group
managing
these
main
guidelines.
If
it
turns
out
that
this
is
indeed
something
that
is
feasible,
you
know,
because
we
don't
even
know
if
it's,
if
it's
that
good
of
an
idea
to
do
this,
for
all
the
protocols
at
the
same
time
or
which
additional
challenges
we
might
face
and
that
that
new
working
group
that
will
interface
with
other
working
groups,
to
define
particular
schemas
for
different
protocols,
but
as
for
in
the
future.
R
For
now,
for
practical
reasons,
mainly,
we
are
keeping
all
of
this
within
the
quick
working
group,
mainly
focusing
on
quickening
street,
but
still
discussing
these
type
of
aspects
hoping
to
to
prepare
something
that
makes
q
log
usable
for
for
different
things
down
the
line.
So
this
work
will
start
happening
in
the
next
couple
of
months.
R
A
Thank
you
robin
for
the
presentation.
Yeah.
Let's
open
up
the
queue,
if
anyone's
got
comments
or
feedback
or
questions,
I
can
see
jabba's
quite
lively,
so
you've
certainly
got
a
group
of
folks
interested
philip
palin
off.
You
go.
S
Have
to
unmute
both
yes,
okay
yeah,
I
was
just
gonna
put
down
a
market.
If
you
do
start
forming
a
working
group,
I
want
to
encrypt
my
log
files.
I
want
to
be
able
to
have
a
standard
format
for
doing
that.
You
know
we.
We've
got
the
message
that
all
data
should
be
encrypted
on
the
wire.
S
It's
about
time.
We
started
encrypting
the
data
at
rest
as
well,
and
the
log
files
are
really
sensitive
information
and
it
should
be
encrypted,
gdpr,
etc,
etc.
S
J
Hey
so
I
I'm
not
against
this
work
in
any
way,
I
think
it's
great
and
it's
necessary
that
this
happened.
I'm
just
wondering
what
it
becoming
a
standard
brings
to
the
table
because
you
know
in
in
many
other
places
things
like
this.
This
kind
of
operational
infrastructure
and
logging
formats
are
done
in
ad
hoc
or
open
source
fashion,
and-
and
indeed
I
think
from
your
slides-
you
have
a
pretty
strong
market
share
already.
Just
from
you
know,
coordination
in
that
kind
of
fashion.
J
So
it's
not
that
I'm
saying
this
should
not
be
a
standard,
but
I'm
just
wondering
what
it
brings
to
the
table,
and
I
made
the
remark
in
in
jabber.
You
know
we
don't
standardize
apis
in
the
ietf
for
lots
of
different
reasons.
I
wonder
if,
if
this
has
some
of
the
same
properties
as
an
api
in
terms
of
defining
latent
behaviors
of
implementations,
that
we
wouldn't
want
to
standardize
just
kind
of
an
open
thought
there,
but
so
so
that's
I
again.
I
I'm
not
saying
don't
do
this
just.
R
Okay,
it's
fair
enough.
Question
has
been
asked
several
times
and
I'm
also
not
sure
if
this
should
be
done
myself.
I
just
look
at
things
like
ipfix
or
netflow
and
see
some
similarities
and
see
that
that
work
has
found
quite
a
bit
of
work
in
the
ietf.
T
Hi,
I
yeah,
I
think
that
I
feel,
like
we've
sort
of
lost
a
tradition
here
like
once
upon
a
time
the
ietf
used
to
standardize
more
file
formats.
In
my
somewhat
educated
opinion,
it
seems
like
we've,
we've
gotten
out
of
the
habit,
but
I
do
think
that
there's
value
there
and
to
to
mark's
point,
I
think
the
one
really
important
thing
will
be
to
figure
out
where
the
edges
of
your
your
standardization
domain
are
and
and
make
space
for
for
non-standard
information
to
be
mixed
into
this
kind
of
log.
R
U
I'm
gonna
try
this
again.
I
don't
know
if
my
audio
is
working
great
thanks,
so
I
think
there
is
value
in
standardizing
this.
I
think
it's
actually
a
mistake
to
think
that
the
ietf
doesn't
standardize
apis.
We
have
standardized
apis
in
the
past
and
file
formats,
so
I
agree
with
ben
about
that.
I
think
part
of
the
value
here,
there's
obvious
interoperability,
value
right
and
that
it's
possible
to
debug,
implementations
and
figure
out
when
there
are
problems
what's
going
on
in
them
and
that
that's
a
that's
a
big
gain.
U
The
second
reason
that
it's
good
to
standardize
this
sort
of
stuff
is
the
standards.
The
standardization
process
is
a
place
for
implementers
to
think
clearly
about
the
impact
of
some
of
these
things
right,
including
the
privacy
concerns
that
were
mentioned
earlier
in
the
presentation
you
know
identifying,
hey.
You
know
these
fields
are
particularly
sensitive.
U
If
you're
going
to
log
this
stuff,
you
know
we
might
recommend
you
know
data
retention
or
destruction,
policies
for
data
that
is
at
this
particular
level
of
sensitivity,
or
you
know
we,
you
know,
we
recommend
that
you
don't
log
the
stuff
at
all.
Unless
you
happen
to
have
errors
in
this
particular
domain,
you
know
I'm
scared
about
the
idea
of
automatic
retention
of
key
log
data
in
the
quantities
of
gigabytes
and
the
way
that
one
of
the
slides
mentioned.
U
I
don't
want
to
encourage
that
to
happen,
but
I
think
if
we
don't
actually
talk
about
the
format
specifically,
we
can't
even
have
the
conversation
about
what
our
best
practices
here.
So
I
think
this
is
interesting.
It
looks
like
useful
work.
A
Cool.
Thank
you
for
the
comments.
You
can
see
a
lot
of
chats
sort
of
saying
that
this
is
you
know,
interesting
work
and
that
the
standardization
of
the
log
seems
seems
like
a
good
idea.
So
yeah
this
is
the
kind
of
fyi.
Let's
continue
discussion
and
thank
you
so
much
robin
for
the
presentation.
You've
provided
a
lot
of
links
for
folks
who
are
interested
to
to
go
forward
and
get
involved
with
it.
So
thank
you
very
much.
A
V
Cool
hello,
so,
on
the
mailing
list
a
couple
of
weeks
ago,
I
sort
of
put
a
call
out
to
get
some
attention
on
this
on
a
draft
that
I've
been
worked
on
all
the
way
back
in
singapore
and
then
sat
on
it
for
a
very
long
time
due
to
procrastination
and
other
priorities.
V
Next
slide,
please!
So
what?
What
is
the
problem
I'm
trying
to
solve?
Well,
I
use
sdp
a
lot
for
signaling
various
media
media,
workflows
inside
of
and
and
outside
of
the
context
that
I
think
a
lot
of
other
people
use
it
in
terms
of
inside
of
sip
and
all
the
rest
of
it,
and
this
draft
tries
to
tries
to
describe
it
inside
of
http,
so
it
could
be
used
like
that.
V
The
other
thing
that
this
draft
is
trying
to
eventually
solve
is
having
the
ability
to
signal
media
where
http
is
the
control
so
to
speak
next
slide.
Please.
V
So
this
is
basically
it
I'm
gonna
breeze
through
this.
So
I
effectively
take
the
stp
data
model
and
apply
it
to
http
header
semantics,
I'm
using
structure
headers
to
do
this,
I'm
using
the
latest
sdp
rfc
for
doing
it,
and
I
have
not
yet
got
a
very
clear
answer
to
all
of
the
parts
of
the
media,
which
is
something
that
adam
roach
had
raised
on
mailing
list.
V
Basically,
I
can
describe
the
the
basics
of
it
and
what
I'm
hoping
out
of
this
discussion
is,
or
at
least
your
feedback
is
what
we
should
do
with
this
and
and
how
that
what
that
might
look
like
next
slide,
so
just
a
really
dumb
naughty
example
of
what
what
this
looks
like
in
the
out
there.
In
my
real
world
implementations,
it
looks
something
very
similar
to
this
next
slide.
V
So
originally
we
were
talking
about
dispatching.
This
chairs
have
been
very
kind
to
encourage
me
to
present
this.
There
are
a
few
places
that
this
could
go
and
I
can
see
that
java
has
already
mentioned
some
of
these
names,
I'm
not
asking
for
a
where
should
this
go,
but
I'm
also,
more
importantly,
asking
for
it
is
this
worth
doing,
because,
although
I've
scratched
my
own
back
with
it,
it's
it's
one
of
those
things
where
if
nobody
else
has
interest
in
it,
it's
probably
not
worth
pursuing
that.
A
Thank
you
for
the
presentation,
james
thanks
for
bringing
it
just
to
get
a
few
eyes
on
it
and
yeah
we'll
open
up
the
queue.
If
anyone
has
comments
or
thoughts
on
the
proposal,
other
places
it
could
go
or
just
any
feedback
generally.
Please
please
step.
A
A
A
I'd
encourage
folks
to
get
up
to
the
mic.
If
you
want
to
have
questions
and.
A
W
Eric
criscolla
hi
yeah,
I
mean
it
seems
that
there's
two
things
here:
one
is
a
re-surrealization
of
the
http
api
in
sorry,
the
sap
format
instructor
header,
which
is
like
you
know,
sdp
like
not
ng,
minus
minus
and
then
the
other
is
hey.
We're
going
to
stuff
in
http
headers,
and
you
know,
I
think,
to
recap.
W
Adam's
comment
I
mean
like
sap
is
really
complicated
and
I'm
sort
of
trying
to
like,
like
wallet,
is
an
enormous
pain
or
an
svd
person
like
I'm,
I'm
because
I'm
like
not
really
persuaded
that,
like
it's,
that
valuable
I'll
put
it
headers
as
opposed
to
in
a
new
structured
format
like
I
don't
see
like
that,
generally
being
helpful,
like
you
know,
for
the
purpose
of
opening
the
header
like.
If
all
the
problem
is
you
want
to
get
the
header
just
basically
for
it.
X
V
Let's,
let's
that's
fair
feedback,
I
don't
I
don't
have
a.
I
don't
have
an
intelligent
enough
response
to.
A
It
okay,
anyone
else,
any
comments
in
the
queue.
A
Otherwise,
we'll
just
continue
the
lively
discussion
that
I've
seen
on
the
list
and
thank
you
again
james
for
taking
the
time
to
come
and
present
present
your
work
to
us
today.
Thank
you.
Thank
you,
okay,
so
we're
on
to
our
final
item
on
the
art
agenda,
jonathan
rosenberg,
I
think
you're
presenting
draft
rosenberg.
X
X
These
days,
that's
a
hard
problem.
Okay,
thanks
everyone.
I'm
going
to
talk
about
this
draft
next
slide
going
to
go
real
quick,
so
we
can
have
time
for
discussion
and
comments.
Let's
say
upfront
by
the
way,
I'm
not
looking
for
dispatch.
This
is
this
is
merely
letting
people
know
about
this
draft
and
looking
for
interested
folks
to
participate
with
us,
the
problem
we're
trying
to
solve
is
to
build
highly
reliable
voice
systems.
X
In
cloud-based
environments
we
have
tons
and
tons
of
back-to-back
user
agents,
often
with
media
widely
deployed
in
server
and
data
center
environments,
full
state,
whether
that's
srtp
state,
rtp,
state,
sdp
state
lots
of
low-level
sip
state
making
high
availability
hard.
Two
things
there,
one
is
hey.
If
a
server
instance
fails,
can
you
allow
new
calls
to
succeed
and
the
much
more
tricky
one
which
is?
The
focus
of
this
draft
is
hey.
If
I've
got
an
spc
or
a
soft
switch
and
it
fails?
How
can
I
actually
make
it
so
that
the
call
doesn't
drop?
X
That's
hard,
that's
not
as
commonly
implemented.
It's
sometimes
done
with
ip
takeover
solutions
with
a
lot
of
state
replication,
but
that's
not
really
amenable
to
cluster
deployments.
So
the
goal
this
draft
is
to
enable
high
availability
in
clusters
of
b2b
ways
that
usually
serve
media,
although
not
limited
to
that
next
slide,
I'm
not
going
to
go
through
this.
There
are
it's
out
of
the
document,
but
we
basically
want
to
recover
a
call
in
two
seconds.
X
We
want
to
support
elastic
expansion,
contraction
of
clusters
and
cloud
environments
and
using
that
to
make
sure
we
can
achieve
active,
calls,
can
get
spread
across
remaining
nodes
in
cluster
and
support
things
like
graceful
shutdown,
next
line.
X
The
basic
architecture
looks
like
this:
you've
got
this
idea
that
there's
a
cluster
of
instances,
whether
that's
a
soft
switch
or
an
spc
or
whatever
you've
got
n
of
them.
X
They
have
some
kind
of
shared
database
which
is
outside
the
scope
of
this
document,
and
the
idea
is
to
recognize
this
notion
of
a
cluster
and
to
introduce
requirements
that
need
to
be
implemented
by
the
upstream
calling
server,
which
can
be
another
b2b
ua
or
a
bunch
of
different
type
of
things,
self
switches
or
whatever,
and
the
calling
server
is
doing
sip
and
rtp
load
balancing
across
the
instances
and,
more
importantly,
when
one
of
those
instances
fail,
we
want
to
define
processes
and
handling
for
the
calling
server
to
sort
of
recover.
X
That
call,
and
the
last
bit
of
what's
in
here
is
in
order
for
this
to
work.
We
need
a
way
to
propagate
information
about
this
cluster,
the
set
of
instances,
their
ips
and
ports,
their
relative
capacities
to
the
upstream
calling
server
in
real
time
super
fast
to
deal
with
different,
aha
situations
and
then
next
slide.
X
So
the
actual
solution
mechanism
is
not
complicated
actually
and-
and
this
is
largely
just
requiring
usage
of
specs-
we
mostly
already
have.
The
only
really
newish
thing
is
a
json
object
format
for
pushing
configuration
of
cluster
members
to
this
calling
server.
But
beyond
that
sort
of
recommending
techniques
like
zip
options,
pings
and
rtp
timeouts
were
already
widely
used
for
rapid
failure,
detection
and
then
and
then
really
mandating
the
implementation
of
invite
with
replaces
as
a
specific
way
to
sort
of
reconstitute
the
state.
X
So
if
an
instance
fails,
we
want
the
calling
server
to
send
an
invite
with
replaces
to
a
different
live
instance
in
that
cluster.
That
instance,
can
just
using
the
dialogue.
Identifiers
rebuild
the
call
generate
a
downstream
invite
if
needed,
using
invite
with
replaces
and
up
and
going
to
do
all
that
in
like
less
than
two
seconds
so
that
people
don't
hang
up
the
call.
X
So
that's
basically
the
solution.
I,
like
I
said
not
looking
to
form
a
working
group,
mostly
call
for
input.
The
goal
is
to
sort
of
do
some
prototyping
and
vet.
This
out
do
some
demos
value.
It
works,
particularly
in
cloud
environments,
and
then
you
know
once
we
have
some
implementations
we'll
come
back
to
explore
standardization,
but
looking
for
pulmonary
questions
or.
A
X
X
Fine
well,
if
anyone
is
interested
in
working
with
us
on
this
again,
if
you're
an
sbc
got,
sbcs
got
soft
switches
conference
bridges.
This
is
going
to
massively
help
the
reliability
of
your
solution.
So
you
know
where
to
find
me
thanks.
Everyone.
Y
Yeah,
so
my
I
guess
my
question
is
what
what
how
much
of
the
existing
ship
would
need
to
support
invite
were
the
places?
Is
it
just
the
immediately
upstream
sbc,
or
are
you
saying
that
everything
in
the
whole
world
needs
to
suddenly
fight
with
their
places?
One
of
those
things
certainly
a
much
easier
lift
than
the
other
yeah.
X
That's
a
great
question,
so
it
is
the
the
upstream
element
from
the
cluster
and
the
downstream
element
from
the
cluster
and
the
hypoth.
The
use
cases
are
sort
of
pretty
fairly
narrowly
constrained
for
this
app
they're,
not
meant
for
the
fundamental
assumption
is
that
the
downstream
ua
is
under
in
the
same
administrative
control
of
the
entity.
That
runs
the
cluster.
If
that's
not
the
case,
this
effect
is
not
applicable.
X
So
the
only
thing
the
spec
is
asking
is
upstream,
so
the
main
real-
and
this
is
why
I
want
a
standard-
is
like
hey
if
I'm
running
a
cloud
voice
network-
and
I
want
my
carrier
to
support-
invite-
replaces
on
their
spc,
I'm
covered
I'm
good
with
my
soft
switches
and
my
whatever
is,
but
I
just
need
the
upstream
guy
to
do
it.
That's
really
all
this
is
asking
great
question.
A
Great,
thank
you.
Well,
thanks
for
the
presentation,
jonathan
and
we'll
continue
the
discussions
on
list
and
thanks
for
presenting
so
we're
just
we
reached
the
end
of
our
formal
agenda.
So
I'll
just
do
a
wrap-up
having
discussed
with
patrick
as
well.
Now
we
can
just
wrap
up
the
dispatch
stuff
concretely
and
say.
The
summary
is
that
we
think
the
date
time
work
needs
a
short-lived
working
group,
so
we'll
just
post
on
a
list
about
that
and
it
seems
to
be
uncontroversial.
A
So
we
think
probably
a
buff
is
not
needed,
but
we'll
just
continue
the
discussion
on
list
about
that
with
the
media
types
work
from
carsten.
We
agree.
It's
a
simple
document,
but
it's
still
likely
to
you
know
not
be
as
simple
as
we
would
hope.
So
we
think
a
working
group
is
needed
and
we'll
discuss
and
clarify
the
scope
and
the
problem
on
on
list
and
then
it
might
be
resulting
in
a
buff
and
then
for
the
http
negotiation
work.
A
It
sounds
api,
http,
api
destined,
but
just
a
bit
more
discussion
on
this
required
to
confirm
and
the
chairs
me
and
patrick.
We
will
post
and
start
that
discussion.
A
So
just
wanted
to
wrap
that
up
and
then
hand
over
to
murray
we've
got
if
you
wanna
just
say
a
few
words
that'll
be
grand
thanks.
Z
Flawless,
I
just
wanted
to
take
this
opportunity
to
thank
mary
for
his
work,
supporting
dispatch
and
also
supporting
me
as
a
new
ad
and
francesca
as
a
new
ad.
This
is
his
last
meeting
as
our
area
director.
So
thank
you
very
much.
Barry.
A
AA
Is
that
the
music?
It's
the
mute
button
that
didn't
work
there
was
some
lag
on
it
anyway,
thanks
murray
and
thanks
everybody
in
the
art
area,
for
the
support
you've
given
me
is,
as
a
d,
I've
been
I've
been
thrilled
working
with
you
guys,
and
I
will
continue
to
work
with
you
as
working
group
chair
somewhere
and
other
such
things.
AA
A
Thanks,
barry
okay,
so
we
just
have
a
few
minutes
left
if
anyone
has
any
aob
to
bring
up.
Otherwise
we
will
close
the
meeting
out
and
give
you
a
little
bit
more
break
time.