►
From YouTube: IETF95-SLIM-20160407-1620
Description
SLIM meeting session at IETF95
2016/04/07 1620
A
Right
for
everybody
who
speaks
today
on
the
on
the
meat
echo
and
in
the
room,
please
be
aware
that
we
have
a
number
of
meat
echo
from
or
we
have
a
number
of
remote
attendees
and
some
presenters.
So
please
be
clearly
and
slowly
and
say
your
name
at
the
mic
and
for
me
to
echo
people.
Please
also
speak
clearly
and
slowly
and
it
should
be
and
not
you
the
meat
echoes
you
could
be
responding
pretty
well,
but
you
know
please
still
be
wary
of
that
everybody
should.
Oh
hello!
A
Is
this
cough
sorry
and
everybody
should
be
aware
of
the
note
well
I'm,
just
laying
it
on
the
screen
in
just
in
case,
and
here
is
our
agenda
for
today.
So
we've
gone
through
the
quick
pre
lemon
preliminaries
set
up,
escribes
and
suction
cup.
To
the
note.
Well,
I've
moved
the
agenda
around
a
little
bit
today,
mostly
because
guten
ours
presentation
nicely
flows
through
the
yep,
see
statement
onto
the
open
issues
so
we'll
go
through
the
slim
new
and
existing
documents.
A
Before
we
talk
about
the
etsy
statement,
which
should
be
pretty
quickly
quick,
we
then
need
to
talk
about
our
open.
Our
main
open
issue
and
any
other
open
issues
that
people
want
to
raise
and
then
we'll
go
ahead
and
have
some.
Maybe
afterwards
we
would
try
and
talk
about
completing
the
work
and
then
the
set
of
things
we
want
to
do
for
the
next
month.
Any
agenda
bashing
from
the
group.
A
A
C
A
B
A
B
Guess
so
for
the
recent
activity
at
the
end
of
the
last
meeting,
Pete
Resnick
suggested
that
the
inner
parts
of
the
email
should
be
message:
/,
r,
SZ,
8
22.
This
was
mainly
to
make
sure
the
individual
language.
Specific
subjects
are
recognized
by
legacy,
clients
and
I.
Think
that's
a
great
idea
and
I've
been
doing
some
testing
with
some
emails
in
that
format
and
they
do
produce
some
pretty
good
results
and
straight
after
his
suggestion,
sean
leonard
suggested
that
message.
B
/
global,
would
be
better
than
message:
/
osea
22,
due
to
its
support
for
utf-8
in
message
bodies-
and
this
is
another
really
good
suggestion.
I've
also
done
some
testing
with
that
with
emails
in
that
format.
But
the
results
aren't
quite
as
good
and
I'm
certain
that
this
is
due
to
the
lack
of
support
for
message:
/
clickable
in
email,
clients
that
I've
tried
so.
B
B
So
I
definitely
prefer
to
use
message
last
global
rather
than
message
/
RFC
822,
because
it
seems
like
exactly
the
right
choice
for
all.
We
want
to
do
and
I
think
once
we
get
better
support
for
message.
/
global
the
results
will
end
up
much
more
like
what
we're
seeing
for
message:
/,
RFC
822
for
legacy
clients
and
that's
as
good
as
we're
going
to
get
full
pelicula
clients
anyway.
B
Section
I
also
want
to
do
some
further
testing
with
a
wider
set
of
user
agents,
so
I
will
need
them
some
volunteers
for
that
I'm,
going
to
put
a
message
on
the
slim
list
to
try
to
get
some
than
people
to
volunteer,
for
that
would
be
really
good.
All
that
is
really
is
to
receive
some
handcrafted
multi-part,
multilingual
emails
for
me
and
feedback
about
how
the
result
look.
A
D
Just
I
think
realistically
will
probably
need
to
support
both
message:
arts
here,
to
to
a
message,
global
and
short-term,
and
we
can
I
think
are
especially
if
we
want
interrupt
with
existing
email,
client.
So
at
least
now
clients
that
can
gracefully
degrade
that
don't
understand
multi-part
multilingual,
but
they
can
still
interpret
it
somewhat
reasonable
way.
So
I
suppose
at
some
point
we
can
discuss
with
you
know
it's
like
must
support
message
associated
to
must,
you
know,
should
support
message
global
or
something
like
that.
Okay,
what
sounds
good?
Okay,.
B
And
also
one
of
the
comments
from
the
last
meeting,
John
Levine
noted
how
the
scooter
considerations
was
lacking,
which
I
kind
of
knew
about
I
didn't
really
know
what
to
put
there
at
that
stage
and
hadn't
put
a
lot
of
time
into
it,
but
he
identified
a
possible
with
you
with
spam
filters
allowing
through
undesirable
content.
If
those
spam
filters
don't
check
all
of
the
inner
parts.
So
what
I've
done
is
I've
rewritten
d,
that
section
of
security
considerations
and
I
will
so
be
that
as
part
of
the
monthly
version
of
the
graphical.
E
B
Requirement
for
for
more
than
one
language,
independent
image,
I
think
that's
going
to
be
helped
by
the
use
of
if
either
message,
/a
c,
8,
22
or
merit
message,
/
global
as
the
the
language
message
parts,
because
in
inside
those
they
could
be
multi-part.
They
want
to
pop
mix.
So
of
course
it
could
have
more
than
one
part
to
it.
So
more
than
one
image
next
slide.
Please,
okay,.
B
So
this
is
a
bit
of
a
summary
almost
of
what
I've
just
said,
but
what's
left
to
do,
there's
more
testing
that
I
want
to
do
with
message.
/
global,
together,
herb,
better
wider
picture
of
how
well
it's
supported
so
need
some
volunteers
on
the
sliminess,
but
I'll,
like
I
said
I'll,
send
a
message
out
on
there.
I
need
to
rewrite
the
document
filled
with
either
message:
/,
global
or
message:
/,
o
SC,
8,
22,
or
a
combination
of
the
two
as
alexei
just
mentioned.
B
So
I'll
have
to
do
that
and
then
that
will
include
the
new
security
considerations
that
mention
the
spam
filters
concern
and
they
also
the
impersonation
concerned
with
using
the
those
and
two
new
inner
types
and
all
the
discussion
will
be
on
that
normal
slim
working
group.
So
we
can
get
a
really
good,
then
going
there.
That's
it
from
me.
So
any
questions
great.
A
A
C
B
A
Okay,
great,
thank
you
any
more
questions
from
people
in
the
room
or
on
the
line,
all
right
Nick.
Thank
you.
So
much
for
this
work.
That's
that's
fantastic!
Please
do
take
those
things
you
suggested
to
the
list
so
that
we
can
talk
and
get
some
people
helping
you
out
on
some
of
those
bits
and
pieces
to
finish
things
off
and
oh
just.
A
B
A
Okay,
great
that's
good
to
know
so.
I
mean
we
ride
me
by
the
time
that
we
will
recover
from
this.
It's
going
to
be
mid
April,
so
perhaps
by
the
mid,
May
or
end
of
May.
It
might
be
a
good
thing
to
target
for
about
that
time.
Cool,
fantastic!
Thank
you!
So
much
brilliant
because
it
will
move
off
on
there
thanks
Nick,
I'm
cool,
so
Randall
do
we
want
to
go
ahead
and
do
your
updates.
F
I
mean
this
is
randall
gallons,
there's
not
really
anything
to
say
about
the
update
are
the
only
changes,
are
some
minor
wording
clarifications
and
things
like
that?
There
was
some
email
comments
with
a
lot
of
requested
changes,
and
I
made
changes
that
were
that
did
not
add
technical
complexity
to
the
document.
F
A
A
F
It's
really
about,
if
there's
some
disagreement
between
Gunnar
and
myself
over
how
to
interpret
the
wording
for
the
existing
Lang
attribute.
So
Gunnar
seems
to
feel
that,
though,
that
the
intent
all
along
for
that
attribute
is
that
it
can
be
used
for
negotiation,
whereas
my
reading
of
the
words
is
that
it
can't-
and
you
know,
obviously,
the
wording
in
the
for
the
existing
attribute
is
extremely
vague.
So
all.
A
Right,
that's
about
it,
I'm
brilliant!
Thank
you
for
that.
Well,
we'll
get
to
some
of
the
more
finer
points
of
that
in
the
in
the
ending
session,
but
cool
awesome,
thanks,
brilliant
and
to
go
back
to
our
list.
The
last
thing
that
we
have
is
the
slim
use
cases.
I
was
very,
very
cheeky.
With
the
slim
use
cases,
document
I
did
send
it
in
before
the
deadline
and
then
I
updated
it
today.
C
A
Just
with
some
clean
up,
because
I
was
using
ID
template
on
from
from
martin
Thompson's
github,
repo
and
I
I
didn't
know
how
to
do
a
few
things
like
make
proper
references
which
now
the
document
has
so
so
that's
one
of
the
additions
you'll
find
that
the
the
slim
use
cases
now
has
proper
references.
It
also
goes
into
a
little
bit
more
of
sort
of
easy
to
understand,
use
cases
or
examples
for
the
use
cases
rather
than
just
an
excellent
explanation
of
them,
and
it
would
be
worth
somebody
taking
a
read-through
of
it.
A
It's
not
so
it's
not
going
to
be
an
RFC
documents.
Obviously
so,
and
you
know
it
just-
have
a
quick
look
through
them
and
make
it.
Let
me
know
if
you
have
any
suggested
changes.
All
of
the
use
cases
are
the
same.
They
just
have
this
extra
bits
of
text,
which
makes
them
a
little
bit
easier
to
understand,
and
then
you
can
see
just
at
the
bottom
there,
the
references
actually
in
that
cool.
So
any
questions
about
the
documents,
use
cases
or
Randall's
docks.
E
A
A
You
know
it's
such
a
short
document.
You
can
actually
sit
there
right,
notes
and
read
it
and
be
present
at
this
meeting.
All
at
the
same
time,
that
would
be
great.
I
was
falling
asleep
and
writing
notes
that
the
previous
meetings,
no
it's
a
yeah
I
on
the
list,
is
fine.
If
you
do
have
time
this
week,
though,
that
would
be
much
appreciated.
Thank
you
very
much.
Randall
I,
just.
F
F
A
That's
great
yeah,
you
know
my
knowledge
isn't
so
much
in
this
area,
so
it's
good
to
have
that
input.
Thanks
cool
all
right,
I'll
address
those
when
I
get
see
the
email
and
any
other
questions,
people
on
the
phone,
no,
nobody
else
in
the
room,
calm,
all
right.
Let's
move
on
gooner
you're
up
I
we're
going
to
go
through
the
etsy
statement
and
then
the
open
issues
that
you
listed
in
your
document
as
well.
So
gooner
are
you
on
the
line?
Hello?
A
A
A
G
A
G
Then
we
let
c
&
M,
tell
sent
lice
and
I
think
it
ended
up
in
slim
for
one
of
the
previous
meetings.
It
was
about
a
work
we
had
in
etsy
with
total
conversation
for
a
majestic
communication
and
that
work
is
now
completed.
So
there
is
now
a
technical
report:
10
3
2
1,
the
total
conversation
for
emergency
communication
implementation
guidelines
and
it's
published,
and
you
have
a
link
there
and
the
the
completion
and
use
of
slim,
the
you
mean
lang.
G
Attributes
are
reported
there
to
be
important
for
successful
support
of
persons
with
different
language
and
morality
needs
in
emergency
services
in
Europe
so
and
the
document.
The
etsy
document
is
just
a
report
about
how
we
can
establish
good
emergency
service
communication,
and
we
see
this.
The
completion
of
this
work
as
important
part
of
it,
and
by
that
I,
recommend
that
for
reading
and
see
how
we
suggest
to
use
slim
output
and
next
slide.
Please
use.
G
Yeah
we
have
this
good
little
document
about
use.
Cases
and
I
would
like
to
see
ch
agreement
that
we
really
intend
to
fulfill
the
use
cases
then
so
this
is
just
to
go
through
of
them.
We,
so
the
goal
should
be
support
of
all
use
cases
except
the
speech
to
speech
service
user,
because
that
is
service
request
or
rather
than
a
language
use
request.
G
We
have
first
single
to
a
language
in
the
same
modality,
which
is
very
simple.
You
want
to
talk
and
listen
in
the
same
language.
We
have
another
well
when
you,
when
you
offer
alternative
languages
in
the
same
modality,
you
say
you:
can
you
see
the
spanish
or
english,
spanish
or
english
and
doesn't
matter?
Then
we
come
into
more
complicated,
fairly
equal
favorite
alternatives
in
different
modalities.
For
example,
I
can
talk
and
hear
russian,
but
I
can
also
assign
russian
sign
language
select.
What
you
want
and
and
number
four
is
a
last
resort
alternative.
G
G
G
G
Another
number
six
is
another
directional
capabilities.
It's
when
you
have
directional
in
different
directions
and
different
modalities.
For
example,
I
want
to
speak
Norwegian,
but
I
don't
hear.
So
I
want
to
read
norwegian
text
and
number
seven
multi-line
language
competence
in
different
modalities
after
offered
from
the
caller,
for
example,
a
multilingual
call
center
calling
out
and
offering
a
lot
of
different
languages
and
modalities,
and
the
answering
part
can
see
that
and
select
whatever
they
want
and
the
last
speech
that
is
weak
or
hard
to
understand
because
of
a
disabilty
I.
G
G
Then,
if
we
look
through
what
we
have
in
the
current
human
Lang
dropped,
we
see
that
some
of
these
are
not
well
covered
and
I
sent
a
mail
today
about
it.
What
to
do
about
it
and
I
see
that
one
thing
that
is
needed
is
a
grouping
agreement
and
another
is
a
priority
indication
that
is
valid
all
through
the
SDP.
G
E
G
A
I
I
mean
on
this,
so
this
the
slide
is
obviously
going
ahead
into
starting
to
talk
about
the
issue
that
we
had.
That
Randall
was
talking
about
previously
and
I.
You
know.
Realistically,
it
would
be
good
if
we
could
clear
this
up
in
this
meeting
so
that
we
can
move
forward
from
that.
I
don't
have
much
understanding
of
the
technology
in
this
area,
although
it
seems
that
there
is
and
there's
a
there's,
a
couple
of
things
here,
one
that
it
might
be
it
sort
of
implementation.
A
H
H
We've
done
a
number
of
grouping
mechanisms
in
various
ways:
there's
several
NM
in
SD
and
we've
done
other
kinds
of
things:
they're
complicated.
They
tend
not
to
be
implemented.
They
don't
seem
to
help
as
much
as
we
thought
they
would
and
I'm
I'm
very
suspicious
of
any
new
grouping
mechanism.
I
just
don't
think
having
having
tried
to
get
people
to
implement
it.
Having
done
some
implementations
myself
and
it
involved
in
several
standards
efforts
on
grouping,
it
always
looks
so
simple
and
always
ends
up
being
hard.
E
F
G
F
Is
randall
gallons?
I
just
wanted
to
reiterate
what
Brian
said
and
what
I
said
earlier,
which
is
that,
in
my
view,
the
simpler
we
keep
this
document,
the
better
we
are
able
to
number
one
get
it
deployed,
get
it
deployed
quickly
and
then
number
two.
We
can
learn
from
that
deployment
and
we
can
extend
it
if
you
need
to
and
that
extension
will
be
based
on
real
needs
and
therefore
we
can
do
it
in
a
way
that
makes
sense
and
we'll
get
also
get
implemented
if
it's
needed.
A
Cool
thank
you
for
that.
That
was
going
to
be
one
of
those
suggestions
as
to
make
something
accessible.
Guna,
you
have
a
couple
more
slides,
so
I
I
suggest
that
you
go
through
lights
now
and
I'm
also
just
gonna
say
because
we
have
some.
We
have
a
few
people
in
the
room.
We
will
have
a
few
people
remote
attending,
but
I
know
it's
difficult.
Remote
attendee
people
can't
participate
humming
and
obviously
that's
supposed
to
be
a
sort
of
anonymous
boat.
A
So
if
you
feel
and
that
you
don't
mind
making
yourself
making
your
opinion
known
on
this
big,
it
would
be
good
if
you
could,
the
remote
attendees
put
something
in
the
jabber
room
to
say.
You
know
how
you
feel
about
this,
because
we
do
want
to
try
and
resolve
this
today
and
so
good
I'll
go
through
to
your
next
slide.
The
current
Lang
attribute.
G
G
F
F
Meaning
of
the
words
I
I
would
disagree
that
that
it's
impossible
and
that
that
can't
be
because
my
reading
of
it
is,
if
that's
exactly
what
it
means,
because
that's
exactly
what
it
says
that
may
not
be
with
amen,
I,
don't
know,
but
my
interpretation
is
that
the
intent
was
that
this
is
used
not
for
real
time
but
for
static
media
where
there
are
multiple
languages
in
there
and
that
that
would
be
useful
thing
to
label
them.
Now
that
you
know
I
could
be
wrong.
You
could
be
wrong.
F
G
F
F
F
How
are
we
going
to
billet
e
to
negotiate
human
language,
and
we
all
agree
that
that
we
could
not
use
the
existing
attribute,
because
it
did
not
seem
to
be
what
we
needed
and
if
we
retract
one
option
was
that
we
said,
let's
just
read:
eclair
the
semantics
of
it
to
be
what
we
want,
which
is
that
you
can
use
it
in
ago.
She
ation,
in
which
case
this
whole
giraffe
goes
away
and
we're
done,
and
when
this
group
does
not
need
to
do
anything,
it.
G
G
H
F
And
I
just
wanted
to
say
that
order
of
importance
does
have
meaning
from
static
media,
because,
if
you're
thinking
of
watching
a
particular
news
clip-
and
it's
got
several
languages
and
there
and
there's
some
of
them-
you
don't
understand
if
they're
the
languages
at
the
end.
You
might
watch
it
anyway,
because
it's
not
that
important.
If
you
don't
get
it.
A
I
Mean
that
was
I
think
Randall
expressed
it
more
or
less
I.
It
was
more
of
a
question
to
gooner.
You
know
there
was
a
sentiment
that
complex
grouping
is
too
complex
and
I
agree
with
that
I'm
just
wondering
if
we
can
use
in
gunas
opinion
whether
order
of
importance
has
any
value
and
can
and
we
can
get
through
some
of
his
use
cases
without
the
grouping.
I.
I
G
G
F
F
A
C
A
G
G
H
H
So
I
I
would
really
like
us
to
try
to
separate
requirements
from
mechanisms.
If
we
decide
we
have
a
requirement
to
do
some
of
these
more
complex
cases,
then
we
need
a
solution
and
we
can
choose
what
solution.
We
need
the
history
of
this
work.
We
have
gone
back
and
forth
in
a
lots
of
ways
of
how
to
do
things
and
mechanism
has
always
been
fraught
with
difficulty.
So
the
but
I
plea
that
we
don't
mix
mechanism
with
requirements.
H
If
we
have
a
requirement
to
do
something
and
the
current
proposed
mechanism
doesn't
do
it
we'll
have
to
fix
that
in
one
way
or
another,
but
let's
not
get
going
on
that
whole
thing
of
how
to
do
something
until
we
decide
that
we
need
to
do
something
because
I
don't
think
we
need
to
do
more
than
we've
done.
Gun
owners
are
arguing.
Otherwise,
so
I'd
like
to
settle
that
question
first
before
we
argue
about
what
mechanism
we
use
to
accomplish
some
requirement
that
we
don't
yet
agree
on
so.
H
C
A
H
A
H
G
G
So
we
need
a
priority
indication
that
it
is
not
bound
to
just
em
line
but
has
relation
all
over
the
sdp,
and
we
need
an
indication
that
two
languages
or
and
modalities
are
required
together,
for
example,
a
need
to
both
hear
voice
and
get
text
or
need
to
talk
and
get
text
back,
and
we
need
to
be
also
more
clear
than
our
CFM
4566.
The
Lang
attribute
about
offer
answer
selection
and
the
required
grouping
so
that
we
don't
fall
in
the
same
category
as
the
current
lang
that
it's
not
usable
because
we
don't
understand
it.
G
I
have
proposed
a
solution
in
mail
a
couple
of
months
before,
but
I
collected
them
again
and
touched
them
up
today
and
my
proposal
because
I
have
no
other,
is
a
Q
value.
/
language
attribute
to
with
a
whole
sdp,
has
scope
and
an
extra
roll
saying
that
if
you
have
the
same
q
value,
it
means
that
that
it
is
a
required
grouping
so
that
it's
a
very
simple
grouping
mechanism.
A
H
Right,
I
I.
Don't
think
that
we
need
to
do
things
that
involve
grouping
I.
Don't
think
that
the
complexity
I
understand
what
the
cleverness
that
that
gets
us
is
I.
Don't
think
that
it
has
enough
practical
value
to
actually
result
to
benefit
from
the
complexity
that
it
introduces
and
I.
I
particularly
don't
like
the
solution
but
I'm
trying
to
avoid
talking
about
the
solution
and
talk
about
the
requirement.
Do
we
have
a
requirement
to
group
I?
H
Don't
think
we
do
I
think
that
we
can
handle
the
cases
the
majority
of
cases
of
interest,
with
much
simpler
mechanisms
that
don't
involve.
Grouping
and
I
prefer
to
concentrate
on
those
things,
especially
as
our
first
step.
We
can
always
go
back
and
fix
things
if
we
decide.
Oh
really,
you
know
it
really
is
important
to
know
the
difference
between.
I
can
speak.
French
and
I
can
sign
Russian,
but
I
prefer
to
you,
know,
wave
my
hands
I
mean
yeah.
We
can't
do
that,
but
I
don't
think
we
have
to
okay.
A
So
I'm
I'm
been
hearing
this
from
a
lot
of
people
I'm,
not
too
sure
of
the
sound
and
I,
don't
think
I
ejected
Paul
from
the
queue
so
I'm,
not
too
sure,
there's
anyone
else
on
the
on
the
remote
you
good
on
Randall
you
mentioned
earlier
about
the
idea
of
maybe
extending
the
work
later
on.
Is
that
something
that
can
happen
to
suit
these
other
use
cases
at
a
later
date.
F
Absolutely
I
mean
is
II,
let's
say
we
get.
We
get
this
document
done.
You
know
in
three
months,
see
I
mean
we
go
through.
You
know
everything
is
published
as
RFC
in
a
couple
of
months
this
year
we
get
some
deployment
experience
and
it
turns
out
there's
some
common
use
case
or
some
important
use
case
where
we
really
do
need
grouping
or
priority.
We
can
then
just
go
in
and
add
an
extension
RFC
that
just
adds
if
it's
a
Q
value
whatever
it
is,
and
we
can
just
say
it
adds
that
and.
H
So
I'm
here
wearing
two
hats.
My
first
met
is:
is
the
jabber
scribe
and
Barnard
says
questions
Brian?
What
is
your
thinking
on
alternatives
to
grouping
ordering
and
now
I
put
my
own
hat
on
and
Brian
Rosen's
at
the
mic
and
he
says
I,
don't
think
we
need
either
I.
Think
that's
just
the
basic
sdp
offer
answer
is
sufficient
to
solve
the
prob,
be
the
majority
of
the
problems,
so
I
I,
don't
think
we
need
either
order
or
grouping
okay.
A
So
I,
just
to
add
to
that
I
come
from
a
software
engineering
background.
They
tend
to
find
this
solving.
Those
smaller
problems
first
tends
to
prove
to
be
more
successful,
generally
and
so
I
to
not,
with
the
chairs
out
on
feel
that
the
solving
the
simpler
problems
first
might
be
a
good
way
to
move
forward.
I
feel
like
solving
the
simpler
problems
first
and
then
having
this
extensibility
is
is
is
the
way
to
keep
everybody
happy
here,
because
we're
not
saying.
A
G
A
Do
have
to
address
the
use
cases
document
and
that
that
mostly,
is
because
somebody
who
didn't
have
a
really
good,
in-depth
understanding
of
this
technology.
I
me
wrote
it,
so
there
is
some
bits
that
need
to
go
into,
but
we
aren't
throwing
away
the
use
cases.
We
will
go
ahead
and
and
address
them
as
part
of
this
extension.
Once
we've
got
this
little
bit
done
beforehand,
I
can't
and.
G
G
A
C
G
I
So
I
mean
I
have
a
few
questions,
one
of
which
is
do
we
have
a
way
of
coming
to
consensus
on
which
use
cases
are
required
in
which
your
optional
and
the
second
question
is,
do
if,
once
we
decide
which
ones
are
required,
do
we
have
a
way
of
coming
a
consensus
on
whether
we
actually
solve
them
with
what
we
have
or
with
some
you
know,
extension
or
rather
I
think
between
those
two
things?
If
we
could
do
those
things,
we
might
be
able
to
have
a
way
forward
that
make
any
sense.
A
Yeah
I
think
this
makes
sense.
So
I
guess
one
good
suggestion
from
that
comment
is
to
take
the
suggestions
for
changes
from
the
use
cases
from
the
group,
so
Randall
sent
Simon
already
Brian's
going
to
send
some
in.
We
can
have
a
bit
please
everybody
else
on
I'll
send
a
message
to
the
list
as
well
and
please
everybody
have
a
look
at
those
use
cases
and
we
can
get
those
working
and
then
off
of
tho
those
agreed
set.
I
G
G
Thing
that
Randall
usually
says
Randall
usually
says
that
what
we
have
is
sufficient
for
selecting
which
media
we
enable
and
I
usually
comment
that
that
is
not
what
we
are
came
for.
We
are
working
for
telling
the
counterparts
what
language
they
in
shall
use.
They
may
have
all
media
included,
and
it's
better
the
more
media
they,
including
the
core
call,
but
it's
how
they
intend
to
behave.
H
That
may
be
doing
in
the
list
might
be
the
ring,
but
but
the
earlier
we
understand
whether
we
have
rough
rough
consensus
on
this
sort
of
fundamental
issue
of.
Do
we
need
do.
We
need
something
more
complex
than
sort
of
basic
SDP,
with
a
way
of
saying
a
language
on
any
media
stream.
Is
that
enough
or
not?
If
we
have
rough
consensus
on
that
and
we're
wasting
a
lot
of
time?
If
we
don't,
we
have
to
work
harder
to
determine
if
we
have
rough
consensus,
I.
F
E
F
World
doesn't
end,
it's
it's
a
little
bit
wasteful,
but
the
point
is
the
communication
happens
and
that's
important,
because
there's
a
difference
between
humans
doing
something
and
being
able
to
express
everything
that
humans
can
do
in
a
technical
way
and
I
I.
Don't
think
we
need
to
express
everything
that
humans
could
possibly
do
in
a
technical
way,
I
think
it's
sufficient.
F
If
we
can
get
the
media
with
an
agreement
of
the
languages,
we
have
really
achieved
a
lot
and
I
think
that
we
have
that
and
if
you
end
up
with
an
extra
media
stream
in
there,
you
don't
have
to
use
it
also.
I
just
wanted
to
point
out
the
original
definition,
and
this
is
we've
been
going
around
and
around
on
this,
but
the
original
in
RFC
4566.
It
says
that
the
lying
attribute
it
says
that
you
can
use
multiple
lying
attributes
at
the
media
level
when
the
media
use
multiple
languages.
F
A
I
G
I
G
A
C
Right
just
a
small
point,
but
it
seems
to
me
I
think
what
Gunners
getting
at.
Is
that
me,
in
addition
to
getting
the
right
media
in
the
call,
there's
the
question
of
getting
the
right
resources
in
the
call
and
in
particular
having
enough
information
to
decide
if
you
need
an
interpreter
or
if
you
can
do
without
one
exactly.
A
H
G
A
Thank
you
so
much
right,
so
I'll
summarize
things
that
we
could
do
from
now
on
and
a
little
bit
of
work
that
we
can
do
between
now
and
the
next
IETF
meeting.
First
of
all,
we
clean
up
the
use
cases
document.
There
seems
to
be
a
thing
that
everybody
feels
is
something
that
needs
to
happen.
We
can
add
this
other
things
about
the
priorities
attached
to
those
use
cases
well,
I
suggested
by
Bernard.
A
The
last
one
I
know
there
was
Christmas
in
the
way,
but
it
was
a
long
time
ago.
So,
ideally,
we
would
like
to
get
these
first-round
of
drafts,
Knicks
and
Randall's
draft
done
by
the
next
IETF
meeting
so
that
we
can
go
ahead
and
look
at
those
extensions
if
they
are
necessary
once
we
decide
that
they're
necessary
on
the
on
the
list.
A
If
you
feel
differently
about
that
either
see
me
if
around
word
well,
if
you're
here,
if
not,
please
send
an
email
to
the
list
preferable
to
me
personally,
if
you
don't
feel
so
happy
with
that,
please
copy
Bernard
as
well,
because
he's
also
co-chair
and
we
will
go
from
there
and
thank
you,
everyone
to
you
who
presented
and
they
I'm,
putting
slides
together
at
very
short
notice
and
let's
work
to
get
things
all
sorted
and
move
things
forward,
so
cool.
Thank
you.
Everyone
you're
free
to
go.
Okay,.