►
From YouTube: IETF96-SLIM-20160719-1000
Description
SLIM meeting session at IETF96
2016/07/19 1000
B
B
We've
got
a
few
things
to
go
through
mostly
around
the
two
documents
that
we
have
will
go
through
the
agenda
quickly.
Lucas
is
our
Java
scrub.
Thank
you
very
much
for
that.
We
do
not
have
a
normal
scribe
with
somebody
like
to
be
the
normal
scribe,
are
so
many
hands
so
much
choice.
Oh,
why
thank
you
Brian.
B
Thank
you.
So
much
for
that.
Any
method
you
prefer
is
fine
I,
so
are
Jabbar
is
limbs
limit.
Jabberjaw
I
have
two
orch
Bernard
and
I
your
chest
over
here
today,
which
is
great
right.
Jab
escribe
we've.
What
we're
passing
around
a
blue
sheet,
just
one
blue
sheet,
make
sure
you
get
it
I
will
check
at
the
end
we
have
ones
outside
during.
We
need
another
one.
B
We
we
do
have
at
least
one
remote
presenter,
green
ours
going
to
be
presenting
remotely
towards
the
end
of
the
meeting.
So
please
speak
clearly
and
slowly
and
say
your
name
into
the
mic.
I
like
when
people
do
slow
named
statements
into
the
mic,
it
seems
to
be
a
thing
ITF,
which
you
have
to
say
your
name
really
really
quickly
into
the
mic
in
the
most
inaudible
fashion.
So
you
get
as
you
don't
get
any
awards
for
saying
your
name
slowly,
it's
just
nice
cool,
alright.
So
this
is
the
note
well.
B
This
is
how
we
do
things
here
at
the
idea.
If
you
can't
abide
by
said
rules
and
please
let
us
know
I,
guess
or
leave
or
one
of
those
things,
it's
very
small,
but
it's
it's
on
the
website.
So
please,
if
you
put
ITF
note
well
into
your
favorite
search
engine,
you'll
be
able
to
find
it
and
press
ctrl
+
until
it's
at
a
font
size
which
is
good
for
you
to
read
cool.
D
A
little
note
about
our
expectations
with
respect
to
IPR
declaration.
There
is
something
called
RFC
6701,
which
is
sanctions
available
for
application
to
violators
of
ITF
IPR
policy,
and
these
are
some
quotes
from
it.
That
we'd
like
to
remind
the
audience
of
the
impact
of
an
IPR
disclosure,
has
on
a
smooth
working
of
the
ITF
is
directly
related
to
how
late
in
the
process
the
disclosure
is
made.
D
The
IPR
situation
is
considered
at
key
times,
such
as
adoption
of
the
document
and
during
last
call
the
slim
working
group
will
be
going
to
work
in
group
last
call
on
several
of
these
documents
shortly,
and
our
expectation
is
that
we
will
receive
IPR
declarations
no
later
than
the
end
of
that
last
call
not
forming
to
the
ITF
scipy.
Our
policy
undermines
the
work
of
the
ITF,
and
sanctions
ought
to
be
applied
against
offenders,
and
working
group
chairs
are
empowered
to
take
action.
B
You're
welcome
on
behalf
of
the
not
cool.
Thank
you
for
that
awesome.
So
yeah
we
have
a
like
I
said.
We
have
a
brief
agenda
today.
We're
going
to
have
a
quick
overview
on
slim.
The
slim
docks
nick
has
a
presentation
to
do
on
a
slim,
multi
multi
line
content.
Oh
sorry,
I
was
specific.
01
there,
it's
01,
not
a
00,
I'm
apologies,
that's
my
mistake
and
random
doesn't
have
slides,
but
we'll
just
perhaps
give
a
quick
verbal
update
on
on
on
negotiating
human
language.
Yes,
that,
second,
then
we're
going
to
have
a
next
steps.
B
Conversation
what's
happening
with
the
documents,
any
new
work
that
we
might
want
to
do,
and
we
have
a
lot
of
overflow
time
cool
all
right.
So
I
think
we'll
move
over
to
nick.
If
you're,
okay,
to
present
that's
fine
I'll,
go
to
the
slides,
all
our
documents,
obviously,
on
data
tracker,
if
you
want
to
have
a
look
at
the
actual
document,
you
know
where
to
go.
Slim
data
tracker,
IDF
in
your
favorite
search
engine
will
find
it
cool
all
right.
F
F
That's
resulting
in
a
new
version
of
the
document.
The
main
comment
that
came
back
resulted
in
quite
a
big
change
to
the
structure
of
the
multi-language
message
itself,
and
the
main
change
now
is
that
the
the
first
part
of
the
multilingual
layout
is
a
single
text
plain
part,
and
after
that
then
you've
got
one
or
more
message:
stash
I
to
the
822
or
message
less
noble
language
parts,
and
they
were
originally.
F
H
F
F
F
So
it
needs
to
be
just
as
simple
as
possible
and
text
plain
I
think
there's
a
good
run
dirt
that
has
tested
really
well
in
emails.
I've
been
sending
around
next
slide,
please
in
the
previous
version.
The
security
considerations
were
non-existent
that
was
picked
up
in
one
of
the
comments
and
I've
now
updated
that
so
that
the
main
concern
that
was
raised
was
for
spam
filters
that
didn't
delve
into
each
individual
sub
part
of
the
message.
I'm,
not
sure
how
light
it
is.
F
F
F
I
have
been
doing
some
testing
with
that
new
format.
It's
worked
pretty
well,
but
I
would
like
to
do
a
little
bit
more
testing
using
the
examples
directly
out
of
the
internet
draft,
just
to
be
absolutely
sure
that
they
they
do
test.
Well,
so
I'll
send
those
through
to
the
list
of
volunteers
that
I
asked
for
last
time
and
I'm
also
going
to
send
it
to
the
slimmest
itself,
so
everyone
can
have
some
fun.
F
F
There
was
also
comment
from
last
time
about
contacting
some
multinational
large
male
providers
getting
them
involved
with
doing
some
preliminary
testing
and
working
towards
potential
implementations.
I'm
not
sure
if
now
is
the
right
time
to
actually
contact
those
people
and
get
them
involved
or
whether
it's
it
should
be
after
the
RFC
is
published
and
then
changes
that
that
they
recommend
could
be
applied
as
a
later
version.
F
So
maybe
some
feedback
on
that
would
be
ideal
and
as
always,
the
discussions
have
been
going
on
this
limb
working
group.
There's
not
a
lot
of
activity
going
on.
I
think
we've
pretty
much
near
the
end
now,
but
that's
the
best
place
of
thing
because
in
wherever
you
are
in
the
world,
you
can
just
join
in
and
doesn't
have
to
be
at
the
actual
event.
So
that's
pretty
much
it
for
me.
F
E
Brian
Rosen
to
that,
to
the
last
point,
I
mean
the
ITF.
Is
you
know,
rough
consensus
of
running
code?
So
now
it's
much
better
than
later.
So
if
we
could
get
folks
to
participate
that
that
would
be
great
I
think
you
got
the
chicken
and
egg
right
which
side
has
to
be
running
before
the
other
side
is
willing
to
participate.
I
think,
as
the
is
the
problem,
I
personally
know
some
folks
who
would
like
to
have
this
work
and
they
generate
mail,
but
they
don't
in
the
infrastructure
right.
E
They
just
use
the
infrastructure,
so
I
think
it's
easy
to
get
people
who
would
like
to
get
this
to
work
yeah
to
try
it
on
large
mail
lists,
but
they
wouldn't
be
willing
to
do
it
unless
both
the
the
system
that
they
use
to
send
mail
and
their
their
target
mail
lists
recipients,
clients
could
both
use
it
and,
and
so
I
think
that
that
we,
you
know
we
have
in
order
to
get
it
to
work.
We
got
a
lot
of
work
to
do,
but
maybe
we
can
all
work.
F
E
I
B
B
G
G
It
looks
pretty
good.
Okay,
that's
good!
Obviously
you
know
I
I,
try
to
I
try
to
put
more
in
and
a
lot
of
people
do
in
their
security
and
privacy
considerations,
so
that
I
try
to
head
off
lots
of
nitpicky
comments
later
on,
but
obviously
I'm
very
happy
to
entertain
any
further
comments
that
people
have
on
it.
One.
B
Tells
me
as
a
chair,
I
need
to
ask
such
questions,
so
things
are
dumb
cool.
Alright,
I'm
holding
oh
I
know
guna
has
some
stuff
Dee,
but
that's
he's
talking
in
the
aob
so
holding
on
gunas
comments.
Does
anybody
else
have
questions
about
this
draft
for
for
round
or
tool
negotiating
human
language
in
the
real-time
draft
who
we're
getting
through
it
cool?
Thank
you
so
much
for
that
random
awesome.
Alright.
So
I
will
switch
back
over
to
the
agenda.
Our
next
topic
is
the
next
steps
for
these
drafts.
B
B
G
And
that's
it
Nick!
You
mentioned
that
you
were.
You
were
growing.
If
I
understand
you,
you
said
you
were
going
to
be
making
some
changes
to
the
security
considerations
section.
So
my
question
is
based
on
the
extent
of
those
changes.
Should
we
wait
for
that
with
vision
and
go
to
worse
working
group
last
call
based
on
that.
H
C
F
A
B
Yeah,
if
you're
happy
with
that,
that's
fine
I'm
great!
Thank
you
so
much
for
that
Nick
all
right!
Oh
note
that
down
the
and.
B
Let's
yeah,
so
let's
rerun
it
are
we
okay,
so
hun?
Now,
if
you
are
happy
with
the
plan
being
that
Nick
will
add
his
items,
security
can
oh.
B
No
sorry
well
now
I'm
getting
confused.
Okay
hum
if
you
Jackie
Schechter,
with
blue
Thank,
You
Barry,
it's
an
uphill
struggle:
okay,
cool
all
right!
So
right,
let's
move
on
to
the
negotiating
human
language
and
real-time
communications
draft.
This
is
something
we've
been
discussing
on
the
list
for
a
long
time.
We
seem
to
resolve
some
issues
that
we
had
on
the
list.
So
it's
a
good
time
to
move
to
working
group.
Last
call
I
do
want
to
take
that
hungriness
on
the.
C
C
K
G
Gather
this
is
randall
gallons.
I
did
take
your
comments
into
consideration.
The
revision
that
I
posted
that
the
one
that's
up
there
did
take
into
consideration
your
comments
that
some
of
the
text
was
either
overly
specific
or
confusing.
So
I
I
did
tone
down
the
discussion
of
the
previous
lang
and
I
did
make
a
few
other
minor
changes
along
those
areas.
G
I
know
you
did
send
another
word
document
I've
been
reviewing
that,
but
I
think
that
we
can
go
to
working
group
last
call
on
this
version
and
then,
if
you
Eddie,
if
you
have
additional
comments,
you
know
we
can
take
that
as
working
group
last
call
comments,
I
mean
I'm
happy
to
make
further
changes.
I
just
don't
see
anything.
That
is
a
that
needs
to
be
done.
You
know
if
you
object,
but
let
me
know
cool.
B
K
G
That
has,
there
is
still
a
discussion
about
the
existing
Lang
attribute
as
justification
for
what
we're
doing
it's
informative.
It's
not
normative,
and
it's
based
on
the
understanding
that
we
had
and
I
did
make
revisions
to
that.
In
view
of
your
comments,
if
you
go
and
look
at
the
data
tracker
history
with
the
side
by
side
gifs,
you
can
see
the
changes
that
were
made
in
that
section
and
into
that
tax.
B
Okay,
cool.
Thank
you
for
that
I
think
Bernard.
You
can
shout
if
you
feel
otherwise
I
think
the
the
plan
of
going
to
work
in
group,
Glasgow
and
taking
action
are
taking
any
more
comments
on
that.
As
working
group
last
call
comments
is
sufficient,
so
we'll
go
on
that
on
the
basis
of
the
harm
and
the
learning
curve
has
been
completed.
I'm
going
to
ask:
does
anyone
object
to
going
to
working
group
last
call
on
this
laughs?
Please
harm
now.
B
D
D
B
Yes,
actually
regards
to
this
I
did
want
to
ask
a
question.
We
do
need
to
work
on
issues
we're
trying
to
work
out,
which
is
the
best
way
to
submit
issues.
If
you
have
any
major
objections
to
use,
we
have
two
possible
methods
right
now,
using
github
for
our
issues
or
using
the
IETF
tracker
issues
tracker.
So
if
you
have
objections
to
either
maybe
post
them
on
the
list,
let's
tell
us
directly.
If
you
feel
really
strongly,
you
can
go
to
the
mic,
but
let
us
know
directly
which,
which
is
something
you
prefer.
B
E
D
B
I
suppose
is
the
author
of
the
draft.
It
feels
a
little
weird,
but
it
was
a
collection
of
use
case
like
collected
from
other
places.
I
think
I
do
have
some
edits
to
do
on
that,
as
so,
I
would
ask
for
the
same
for
the
same
thing
as
Nick.
Actually,
if
I
could
have
a
look
at
it
over
the
next
few
days
and
move
to
working
group
last
call
on
it
on
friday
at
the
end
of
the
meeting,
I
would
be
very
happy
with
that.
As
an
author
Randall
is
that
the
queue
I
I.
G
Also,
just
this
is
randall
gallons.
I
just
had
a
comment
on
moving
too
well
on
publishing
the
use
cases,
because
my
recollection
is
that
at
the
time
that
we
pulled
the
youth
cases
out
of
the
the
human
language,
real-time
draft
and
moved
in
their
own
section
on
document.
My
understand,
my
recollection
is
that
we
just
said
we
weren't
going
to
publish
that
as
an
RFC
right.
G
D
B
Yeah,
actually
that's
a
that's
a
very
good
point
and
I
didn't
I
did
imagine
originally
that
it
would
be
informational
and
helpful
to
the
situation
that
we
had
at
that
time
rather
than
official
document.
So
if
people
are
happy
with
that,
then
I'm
happy
to
just
clean
it
up
and
leave
it
as
informational
than
that
out.
Yet
that's
that's.
Okay!
Well,.
D
Maybe
maybe
a
the
appropriate
thing
would
be
to
try
to
get
a
consensus
of
the
working
group,
whether
that
is
something
we
even
want
to
publish
or
not
right,
because
if
there's
always
a
lot
of
work
associated
with
publishing
anything
right
and
it'll
take
up
working
group
time
and
etc.
So
does
that
make
sense.
G
Yep
I
support
decide
first,
if
we
want
to
go
through
that
overhead,
because
my
understanding
was
at
the
back
at
the
time
that
we
separated
it
out,
we
weren't
going
to
publish
it
and
we
somehow
slipped
into
this
understanding
that
we
would
and
I
want
us
to
just
make
sure
we
discuss
that
explicitly
right.
So.
D
E
E
Both
sides
of
you,
yeah,
generat,
generally
speaking,
I,
think
that
it's
helpful
for
history
to
know
why
things
were
done.
The
way
they
were
done,
because
when
people
come
along
trying
to
solve
whatever
problem
they
have,
they
need
things
to
enter,
to
look
at
to
see
why
it
was
done
a
particular
way
and
use
cases
are
really
helpful
for
understanding
why
things
were
done
other
way,
so
on
that
sense,
I'd
like
to
see
it
published.
On
the
other
hand,
this
is
a
small
group
with
that
has
a
limited
amount
of
energy.
E
L
Robert
sparks
the
other
graphs,
don't
reference
the
use
case
document
correct.
Can
you
hand
the
other
dress
to
a
arbitrary
person
in
the
ITF,
say
some
sector
or
general
reviewer,
and
have
them
not
knowing
anything
about
the
use
case
document
at
all.
Have
the
documents
think
that
they
would
understand
everything
understand
the
motivation
for
why
things
were
built,
or
do
you
think
that
they
need
to
be
informed
by
what
was
in
a
use
case
document
in
order
to
be
able
to
properly
understand
the
documents.
D
My
personal
response
to
that
and
I'd
certainly
like
to
hear
others
views
is
that
I
don't
think
you
need
to
read
the
use
case
statement
to
understand
the
applicability
of
of
the
other
one
I
mean
I.
Think
you
can
understand
what
it
can
do.
It
might
be
useful
to
understand
other
things
that
people
might
want
to
do
that
on
document,
but
but
not
for
the
not
for
the
document,
but
certainly
willing
to
hear
other
people's
opinion
on
that.
So.
L
With
what
I'm
hearing
I
would
suggest
that
you
don't
publish
it
unless
the
reviewers
come
back
and
say:
hey
what's
going
on
here
and
you'd
have
to
point
to
that
document
to
explain
it.
The
isg
is
I
was
exiting.
The
isg
was
starting
to
push
back
pretty
hard
against
those
kinds
of
documents
I'm
just
because
the
extra
work
that
it
took
that
that
layer
so
understand,
Brian's
point
but
I.
It
sounds
to
me,
like
you've,
actually
moved
the
parts
of
that
that
are
important
in
two
documents
or.
G
That
at
the
time
that
we
did
take
it
out,
I
think
I'm.
The
understanding
that
we
were
proceeding
on
back
then
was
that
we
would
just
do
it
as
publish
the
use
cases
as
a
working
group,
wiki
page
or
a
working
group
web
page,
so
that
it
was
very
low
overhead,
but
it
was
there
for
anyone
who
wanted
to
look
at
it.
I
Alexei
Melnikov
I
will
actually
second
Roberts.
Opinion
is
eyes.
G
doesn't
quite
like
reviewing
this
case
documents
unless
that
part
of
big
something
bigger
or
you
know
a
section
in
existing
document,
because
there
is
alone
there
was
a
long
discussion
I
she
recently
about
documents
which
are
not
necessarily
going
to
add
value
long
term
so,
but
so,
if,
if
you
as
chairs
are
collectively,
the
working
group
want
to
argue
that
use
case
is
absolutely
necessary,
for
you
know
to
be
our
cart
and
RFC
series,
then
I
think
our
I.
B
Yeah
I
think
that's
it
so
yeah
we'll
do
that
and
send
the
other
other
documents
through
the
process
and
then
go
back
to
it
if
they
flag
it
as
the
other
documents
not
indicating
that
there
what
or
indicative
of
what
they're
trying
to
achieve
great
cool.
Thank
you
so
much
for
those
comments.
Guys
right
guna,
you
are
I'm
gonna,
just
put
your
slides
up
quickly.
Okay,
go
ahead!
Tell
me
when
to
change,
slides,
okay,.
K
K
If
this
information
might
be
lost,
we
could
check
if
we
can
comment
in
the
draft
itself.
What
is
not
covered
in
some
kind
of
scope,
statement
or
so
I
also
agree
that
it
is
a
lot
of
work
to
publish
these
cases
as
a
proper
document,
and
we
should
look
for
other
ways
to
do
it
so
that,
just
as
you
decided
now
for
can.
G
I
just
jump
in
at
one
point
very
briefly:
if
we
publish
it
as
a
working
group
web,
you
know
page
on
the
working
group
website,
then
it's
not
lost
to
history.
It's
all
there.
K
F
K
In
the
draft,
a
chapter
5
with
a
long
reasoning
about
the
sdp
Lang
attribute
and
a
conclusion
that
I
see
is
wrong
and
that's
why
I
feel
we
shouldn't
have
such
discussion,
especially
if
it's
not
needed
the.
What
this
discussion
says
is
that
all
declared
languages
must
be
used
in
the
session,
but
it's
much
more
likely
that
it
is
meant
to
be
a
list
for
selection
and
negotiation,
and
you
can
pick
the
language
or
the
languages.
K
They
change
the
importance
to
preference
so
that
it's
clear,
if
you
have
a
preference,
it's
quite
clear
that
you
want
to
do
a
selection
from
it
and
there
is
also
curl
of
lines
added.
The
the
events
during
the
session
can
influence
which
languages
are
used
and
the
participants
are
not
strictly
bar
bound
to
you
only
use
it
declared
languages.
So
it
is
what
you
agree
on
is
the
initial
languages.
K
M
K
Suggest
that
we
modify
this
drastically
text,
we
have
about
the
current
Lang
attribute,
so
that
is
just
says
that
Lang
cannot
be
used
because
it
does
not
support
different
languages
in
different
directions,
which
is
a
thing
that
we
have
added
and
is
needed
for
some
use
cases.
So
we
should
not,
and
we
do
not
need
to
document
any
assumptions
on
the
current
Lang
attribute.
That
may
be
wrong.
That
would
cause
just
cause
problems.
So
the
little
section.
K
K
K
K
D
D
Gooner,
so
it
says,
is
no
no
requirement
to
use
all
specified
languages,
but
it's
not
like
the
Lang
attribute
where
you
might
use
some
other
language
right.
You
you
have
to
you,
don't
have
to
use
everything
you
negotiate,
but
you
can't.
Can
you
still
go
and
do
something
else
completely
different
that
you
never
negotiated?
That's
that's
a
tsk!
Oh
right,.
K
There
is
a
statement
in
a
draft
saying
that
the
answerer
is
not
bound
to
use
the
languages
that
were
specified
by
the
by
the
offer
which
I,
dull
I.
Think
that
looks
strange,
but
I
haven't
commented
on
that.
They
say
this
discussion
is
rather
make
it
really
clear
that
we
don't
need
to
talk
all
the
languages.
We
specify
that
we
can
do
a
selection
and
just
limit
to
one
language.
I
say
that
I
can
do
swedish
and
english
and
you
respond
english,
and
then
we
go
with
that.
G
K
K
So
this
section
here
is:
there
are
two
attributes
on
handing
in
sand
and
the
other
hand
to
indicate
the
language
use
when
sending
and
receiving
media,
and
we,
the
first
proposal,
is
to
delete
the
yellow
part
here.
So
just
starting
with
sanding
saying
that
is
a
center
and
they
receive
attribute
and
then
in
the
sentence
in
an
offer.
K
The
human,
lungs
and
values
constitute
a
list
of
in
preference
order
of
the
languages
they
offer
wishes
to
send
using
the
media
and
I
suggest
to
change
wishes
to
to
is
capable
to
select
to
change,
to
send
and
similarly
for
receiving
side.
So
the
user
doesn't
wish
to
send
all
the
languages
he
specified
from
the
beginning.
It
is
a
list
of
what
is
capable
to
select
from.
K
K
F
K
G
I'm
not
sure
that
I
am
following
Gunners
problem
with
this
text.
The
wording
here
is
intended
to
differentiate
between
two
broad
types
of
media
streams.
One
type
is
where
you
are
using
it
for
human
communication
in
a
language.
The
other
media
type
is
where
you
are
not
going
to
do
that.
It's
just
background
information
you're
not
going
to
be
talking
over
the
channel.
It's
just
providing
audio
as
an
example
or
you're
not
going
to
be
using
a
video
channel
for
sign
language.
It's
merely
a
background
for
the
other
party
to
be
able
to
see.
G
What's
going
on
in
an
emergency
call,
for
example,
the
peace
app
that's
the
meaning
of
intended
for
human
language
communication
is
to
indicate
when
you
specify
a
language
attribute
and
when
you
don't
right,
but-
and
this
gets
back
to
my
core
point,
which
is
that
I
think
part
of
your
objection
to
some
of
the
material
here
is
based
on
a
misunderstanding,
or
at
least
a
difference
in
understanding
between
what
many
of
us
see
is
the
intent
to
the
draft
which
is
to
specify
and
to
enable
a
technical
communication
and
agreement
versus
user
level.
Interaction.
G
E
Brock
Rosen
I'm
going
to
repeat
what
randy
says:
this
is
a
protocol
mechanism
for
mechanical
use.
It
is
not
an
indication
to
users
of
how
to
behave,
there's
a
fundamental
difference.
This
is
a
protocol
mechanism
to
use
to
direct
calls
to
make
decisions
on
how
calls
are
routed
and
what
is
presented.
It
is
not
how
humans
are
supposed
to
behave,
big
difference
and
that's
the
part
that
we
keep
running
across
it
exactly
so.
G
What
the
UI
does
is
completely
out
of
scope
of
this
draft.
So
as
an
example,
if
you
have
a
UI
where
the
user
has
indicated
in
preferences
or
in
setup
what
languages
and
media
are
preferred
in
what
order
and
then
that
you
I,
starts
a
call
and
uses
the
mechanisms
in
this
document
to
set
up
multiple
media
streams
and
manages
to
get
everything
it
asks
for.
The
UI
is
not
obligated
to
present
to
the
user
everything
the
UI
does
whatever
make
sense.
G
D
And
that's
actually
not
that
different
from
what's
happening
right
now
in
this
room
we
have
all
these.
We
have
video,
we
have
audio,
we
have
text,
it
doesn't
mean
that
you
know.
Randall
now
has
to
be
typing
in
the
chat
room
right
or
has
to
be
talking.
You
have
all
those
capabilities
ready
to
user
can
use
whatever
they
want.
Yeah.
G
G
See
I
I
feel
that's
out
of
scope
of
this
draft.
If
you
want
to
write
a
different
draft,
that
is
advice
to
the
you
to
the
implementer
of
a
client,
that's
making
use
of
this
mechanism,
that's
fine!
You
can
have
that.
That
would
be
guidance
for
how
to
construct
a
user
interface.
But
that's
not
the
should
not
be
in
this
draft.
K
G
D
M
This
is
Dave
Crocker
I
have
not
read
the
spec.
I
have
no
comment
on
the
spec.
I
do
have
a
comment
because
I
always
get
up
at
the
mic
when
someone
says
that
an
ietf
protocol
spec
should
say
something
about
user
behavior,
and
that
is
we
don't
do
that
when
we
try
to
do
it,
we
do
it
badly.
We
don't
need
to
do
it.
We
shouldn't
do
it.
E
Brian
Brian
Rosen,
no
we're
not
providing
any
guidance
to
users
we're
building
protocol
mechanisms.
The
intent
of
the
document
is
to
describe
a
protocol
mechanism
for
mechanical
for
computers
to
do
the
right
thing
not
for
humans
to
do
the
right
thing:
there's
no
guidance
to
users
here
we
don't
intend
to
inform
users
of
what
to
do.
This
is
a
protocol
mechanism
for
mechanical
for
computers
or
other
physical
implementations
of
the
protocol
to
do
the
right
thing
with
the
media
and
routing
and
all
the
other
things
that
we
do
know
how
to
do
in
the
ITF.
M
Dave
Crocker
again
I
apologize
I
was
much
too
terse
than
what
I
said.
What
I
meant
was
anything
having
to
do
with
interactions
with
users
is
part
of
a
specialty,
called
user
experience,
usability
and
any
number
of
other
terms
of
art.
We
don't
have
that
expertise
in
this
community.
There
are
some
individuals
who
do,
but
the
community
doesn't
and
our
specs
must
stay
away
from
that
domain.
G
G
And
that's
the
layers,
that's
that
stuff.
The
filters
down
the
user
has
indicated
to
the
UI
through
the
UI
in
some
way.
That's
completely
out
of
scope
of
this
document.
What
the
users
preferences
are
all
that
stuff
gets
into
the
client
and
then
the
client
uses
the
mechanisms
here
to
set
up
what's
going
to
happen,
and
then
the
client
informs
the
user
in
some
way.
That's
completely
out
of
scope
of
this
document
as
to
what's
happened
now,.
A
This
is
very
limited
to
really
drill
down
on
that
this.
The
way
you
get
the
indication
from
the
user
of
what
language
they
want
to
use
can
be
an
explicit
selection
from
a
list
or
simply
what
store
they
went
to
to
buy
this
product
and
what
language
it
comes
in.
So
you
know
trying
to
do
anything
more
than
saying
you
are
reflecting
a
user's
preference
for
language
communication.
Anything
more
than
that
is
has
got
to
be
out
of
scope,
yeah.
K
K
K
J
K
It
is
really
realistic
to
ever
automatically
fail
calls
because
of
non
matching
language
indications.
You
can
have
combinations,
you
never
thought
of
specifying
they
will
work
in
reality.
For
example,
Norwegians
can
usually
talk
with
Swedes
Spanish
people
can
usually
talk
with
Italians,
and
you
never
thought
about
saying
in
the
setting
of
the
phone
that
yes,
I
can
receive
Norwegian
or
Italian
if
you
are
from
the
other
country.
K
E
E
Yeah
this
is
the
brine
rosen
arm.
There
are
many
reasons
in
protocol
mechanisms
to
have
that
kind
of
alien
mechanisms,
explicit
failing
call.
A
great
example
would
be
us
a
sip
fork.
You
fork
to
four
places
looking
for
some
facility
that
can
handle
the
specific
language.
Is
you
want
three
of
them
decline?
The
call
one
of
them
accepts
the
call
and
you
go
to
take
it
the
way
they
were
one
that
accepts
it.
E
B
G
Want
to
reiterate
that
last
bit
that
Brian
said
there's
nothing
in
the
draft
that
mandates
failure
of
a
call.
Instead,
all
that
that's
in
here
is
talk
about
preference
for
for
proceeding
or
not
proceeding
in
the
event
of
the
mismatch,
preference
for
and
in
fact
the
draft
explicitly
says
that
there
are
cases
where
a
call
will
probably
never
be
failed,
no
matter
what
such
as
an
emergency
call.
That's
we're
not
trying
to
force
anything
on.
B
Hey
I
think
Barry
was
going
to
agree
that
cool
okay
go
ahead.
Okay,.
K
K
And
that
is
when
we
get
into
media
that
are
not
using
any
of
our
time
types
them
main
types,
video
body
or
text.
For
example.
If
we
go
into
WebRTC
and
use
sdp
for
it,
we
need
an
additional
construct-
probably
not
in
this
draft,
but
that's
work
to
be
done
to
have
a
multiplexed
data
channel
to
be
declared
as
used
for
text,
for
example,
and
we
need
to
work
on
that
so
that
we
can
use
this
mechanism
also
in
WebRTC
and
other
places
where
the
media
is
not
typed.
K
G
What's
there
now
is
a
very
small
statement,
and
then
a
parenthetical
aside
about
it
is
that
the
interpretation
of
the
authors
of
the
draft
so
I,
don't
think
there's
anything
in
there
that
constrains
any
future
revision
of
the
of
the
document
of
the
attribute
at
all.
If,
in
fact,
if
you
want
to
project
what's
in
the
draft
now
I'd
like
to
hear
if
anybody
feels
that
that
should
be
taken
out
or
that
needs
to
be
modified.
Well,.
C
G
D
G
Rfc
4
5
6
6
specifies
an
attribute
line
which
appears
similar.
What
is
needed
here
this
specifies
that
I
equals
line
is
declarative,
which
it
does,
and
it
says
that
multiple
Lang
media
use
multiple
languages,
and
that
quote
the
order
of
the
attributes
indicates
the
order
of
importance
of
the
various
languages
in
the
ellipsis
media,
close
quote,
and
then
there's
a
parenthetical
aside.
That
is,
we
meaning
the
author's.
G
G
D
D
Previously
we
had
a
consensus
that
this
discussion
of
the
interpretation
of
4566
would
be
may
a
by
the
working
group
that
owns
the
revision.
Sure.
So
that's
so
your
assertion
that
bet
that
we
already
decided
that
that
would
go
there.
So
you
know
in
arguments
about
interpretation
of
a
document.
That's
owned
by
another
working
group.
Probably
isn't
right
the
right
thing
to
be
doing
in
this
working
group
and
I.
D
F
G
I'm
all
right
I
mean
I,
think
probably
the
less
said
about
the
existing
one,
the
better,
but
we
do
need
to
say
something
to
indicate
why
we're
not
using
it
and
I'm,
not
sure
that
Gunnar's
Texas
is
necessary,
but
perhaps
we
could
say
even
less.
That
might
be
good
enough,
yeah,
okay!
So
then
there
was
one
more
slide.
G
B
D
F
G
And
I
very
quickly,
I
think
we
can
resolve
this
particular
slide
because
they
didn't
comment
on
this
one.
You
presented
it,
so
your
objection
really
is
the
wording
where
that
says
wishes,
and
so,
if
we
change
wishes
to
keep
a
built,
is
capable
of
I
don't
like
is
capable
to
select
two
because
to
me
that
doesn't
make
sense,
but
we
can
just
change
wishes
to
send
or
wishes
to
use
to
say
is
capable
of
yeah.
That's
probably
good
enough.
B
Great
Haim,
thank
you
going
on
for
that.
I'm
gonna
press,
the
big
red
button
again.
B
B
Ok,
goo,
not
add
yourself
back
to
the
list.
If
you
do
have
anything
that
you
want
to
say
more.
On
top
of
that
sorry,
ok,
cool,
we're
at
any
other
business.
I'll
wrap
new
work
into
any
of
the
business
as
well
I'm.
B
The
future
of
this
working
group
is,
you
know,
right
now
to
complete
the
two
documents
to
go
for
the
rse
process,
the
two
documents
that
we
have
and
then
probably
wrap
the
group
up.
So
I
don't
know
if
there
is
any
more
work
for
us
to
do.
This
might
be
a
discussion
for
the
list,
but
you
can
feel
free
to
come
to
the
mic
and
make
a
comment.
Yes,
hi.
B
N
I
just
feel
like
the
security
considerations
in
the
use
case
document
isn't
mentioned
in
those
other
two
documents.
I,
don't
know
enough
about
the
what's
in
the
two
other
documents
that
are
going
for
final
call
as
I
like
the
text,
that's
in
the
use
cases
document
and
would
love
to
see
that
make
it
somewhere
else,
rather
than
to
go
away.
F
B
N
B
D
Actually,
I
do
recall
that
one
of
the
the
security
ID
actually
mentioned
that
he
was
concerned
about
that
text.
So
anyway,
that's
something
to
bring
up
I
think
during
working
with
less
call.
B
Excellent,
thank
you
for
that
brilliant,
ok,
so
this
group
will
then
work
towards
completing
those
two
documents
and
moving
them
in
if
you're
moving
them
up
to
the
RFC
tree.
If
you
have
a
comments
on
new
work
that
can
begin
after
that,
then
please
make
it,
though
I
will
state
that
the
goal
of
this
group
was
to
complete
those
two
documents.
B
Does
anybody
else
have
any
other
business
great
so
just
to
say
thank
you
to
Brian
prescribing
and
Lucas
for
being
our
Java
scrub
and
Randall
and
Nick
&
goo
na
for
being
our
presenters
and
Randall
Nick
in
particular,
for
writing
the
troughs
much
of
the
work
of
this
group.
We
have
a
lot
of
a
DS
here
past
and
present.