►
From YouTube: IETF106-EXTRA-20191118-1430
Description
EXTRA meeting session at IETF106
2019/11/18 1430
https://datatracker.ietf.org/meeting/106/proceedings/
B
B
B
This
is
the
rough
agenda
that
I've
put
together.
Does
anyone
have
anything
I
want
to
add
or
revise
on
this
before
we
get
started?
I,
don't
see
anyone
jumping
up,
so,
let's
dive
straight
into
a
fetch
preview.
The
big
area
of
discussion
here
is
about
the
extension
mechanism,
whether
anyone's
actually
going
to
use
the
extension
mechanism.
That's
there
and
the
options
are
roughly
either
keep.
What's
there,
it
works
or
removes
the
extensibility
now
and
we
can
always
add
in
a
preview
with
more
complexity.
C
So
my
contention
on
this
is
that
the
client
can't
possibly
have
any
idea
what
the
best
way
to
get
a
preview
of
a
document
that
lives
on
the
server
the
only
possible
place.
The
knot
that
knowledge
could
exist
if
it
does
at
all
is
on
the
server
side
and
I.
Think
having
the
client
say
use
this
algorithm
to
do
your
preview
is
pointless.
I
would
rather
just
have
the
client
say,
give
me
a
preview
and
have
the
server
figure
out
the
best
way
to
do
that
and
I
think
that's
what
makes
sense.
C
It
simplifies
the
protocol
and
it
simplifies
the
implementation,
and
then
the
server
can
know
whether
it's
a
text
or
a
video
or
an
audio
part
or
a
JPEG
or
whatever
it
is,
and
do
what
it
needs
to
do
to
make
some
sense
out
of
it.
Does
anyone
think
that's
not
the
right
answer,
other
than
Michael
that
Michael
and
I
have
been
going
back
and
forth?
Okay,.
E
Look
at
this
the
same
way,
I
will
say
that
everybody
internally
feels
the
same
way
that
I
do
where
we
don't
see
how,
if
you're,
looking
at
this
from
a
client
author
perspective,
a
client
author
has
certain
ways
that
they
can
show
information
to
the
user.
It's
the
client
job
is
to
make
that
user
user
interface
determination.
If
all
of
a
sudden
it
starts
getting
information
from
a
server
or,
but
it
has
no
idea
how
to
handle
this
is
completely
worthless.
This
is
not
something
that
we
would
ever
implement.
E
E
You
know
because
I'm
as
a
client,
that's
the
one
thing
I
could
do.
I
do
have
you
know,
since
that
we
last
talked
I've
actually
talked
with
several
customers
who
keep
asking
me
about
image
previews
as,
but
they
also
want
to
stress
to
me
personally
that
they
don't
want
that.
They
want
the
option
to
have
both
a
text
preview
and
an
image
preview,
and
those
are
separate
that
should
not
be
part
of
the
same
sort
of
preview
because
they
want
to
be
able
to
choose.
C
More
information
than
I
had
before
I
think
I
misunderstand:
maybe
your
use
case.
The
use
case
that
I've
see
for
this
is
I'm.
Looking
at
my
messages
in
in
my
inbox
and
I,
see
a
list
with
subject
and
whatever,
and
you
have
a
preview
by
them
like
Gmail
does
for
me.
It
gives
me
the
first
couple
of
lines
of
the
message.
If
that's
your
use
case,
then
what
I'm
saying
is
the
only
thing
that
makes
sense
to
me.
C
D
D
E
C
C
F
Yeah
I
think
this
is
Neil.
Jenkins
I
have
two
questions
so,
firstly,
he
said
you've
got
customers
asking
you
for
these
image
previews
great,
so
we
got
a
use
case.
What
are
those
customers?
What
do
they
want
to
do
with
it
and
then?
Secondly,
from
the
sound
of
it?
What
you
actually
want
with
the
is
for
the
client
to
tell
the
server
I'm
prepared
to
accept
previews
of
type
text,
/
plain
and
possibly
being
able
to
put
image
flash
pindy
or
whatever
mine
choice
they
want
to
accept.
F
E
E
Yeah,
the
first
part
of
let
me
answer
your
first
part.
First
Neal,
there's
actually
two
different
use
cases
that
have
come
up.
One
is
in
general.
You
know
we
have
some
customers
that
want
to
have
like
a
portal.
You
know
they
have
their
own
portal,
they
want
to
show
three
messages
and
they
don't
want
to
show
text
for
messages.
Necessarily
they
have
like
a
photograph.
I
did
rather
show
a
photograph.
Potentially
you
know
this
isn't
a
you
know.
E
They
don't
have
a
defined
use
case,
but
it's
definitely
one
of
the
ideas
that
they
have,
because
that's
a
more
interesting
thing
for
a
customer.
Looking
at
when
they're
looking
at
a
portal
rather
than
you
know,
Grandma,
send
you
a
photograph
rather
than
you
know
some
sort
of
text.
Another
option
is
part
of
art.
E
The
chat
work
that
we're
doing
some
of
these
chat
messages
will
come
already
embedded
with
a
because
the
chat
message
itself
was
encrypted,
but
I
guess
this
is
the
way
that
whatsapp
does
it
is
they
take
the
image
and
they
they
send
a
very,
very,
very
blurred
representation
of
that
image,
and
that's
the
thing
that
you
know
as
a
preview,
because
that's
that's
what
you're
going
to
preview
to
the
user
and
then
users
going
to
click
on
that
image
and
it
actually
will
load
the
full
image.
So
those
are
two
potential
use,
use
cases
and.
C
There's
a
per
that
last
one
is
a
perfect
example
of
where
I
think
the
current
mechanism
of
specifying
algorithms
doesn't
work,
because
the
there's
the
case
where
you
have
all
you
have
is
a
JPEG,
and
maybe
it's
this
enormous
JPEG
and
you
want
the
server
to
transcode
it
into
some
small
JPEG
to
send
as
a
preview.
The
other
is
where
you
have
an
encrypted
JPEG
along
with
an
unencrypted
blurred
version
of
it,
and
you
want
the
server
to
return
the
unencrypted
blurred
version
from
the
clients
point
of
view.
C
In
both
cases,
it's
gotten
an
image
preview,
but
there
are
two
different
algorithms
for
doing
that,
and
so
that's
what
I'm
getting
at
that
the
client
doesn't
know
what
the
best
way
to
get
an
image
preview
is
what
what
Alexei
was
saying.
It
makes
more
sense
to
me
that
if
you
say,
I
want
to
I
want
text
previews
and
image
previews
and
that
let
the
server
figure
out
how
to
do
that,
so
the
media
type
makes
more
sense
than
than
a
preview
algorithm.
C
C
C
Another
is
that
the
text
is
this
travel
log
and
the
image
is
a
smiley
face,
and
in
that
case
the
preview
you
want
is
just
to
snap
something
in
the
text
and
the
image
is
irrelevant
and
another
is
where
you
say,
check
this
out
and
then
there's
a
big
picture.
That's
that's
the
gist
of
it
and
the
in
the
preview
you
want.
There
is
just
the
picture.
You
don't
want
the
crap
in
the
text
and
I,
don't
know
how
a
client
would
convey
what
it
wants
there
in
any
reasonable
sense.
C
The
server
can
use
heuristics
to
figure
out
whether
there's
intelligence
in
the
text
or
not
whether
whether
the
image
is
worth
sending
and
kind
of
stuff.
So
I'm
happier
if
we
go
with
the
client
telling
the
server
what
what
media
types
it
wants
and
let
the
server
figure
out
how
to
do
that.
That
makes
sense
to
me
Neil.
F
Jenkins
again,
I
was
the
exactly
the
same
thing.
The
other
thing
that
that
leap
brings
lead
you
to.
Is
you
want
multiple
previous
returned
text
and
an
image
if,
if
there
are
both
know
they're
useful,
just
all
that
off
my
head,
I
would
probably
go
with
a
well
know.
She
I,
don't
know,
there's
various
different
ways.
You
could
request
that
and
it's
a
bit
complicated
in
trying
to
make
it
not
too
complicated.
Overall,
this
is
worthwhile
yeah
I
I
would
just
go
we're
gonna.
C
If
we're
gonna
do
that,
I
would
just
go
with
the
simplest
thing
where
the
client
says
these
media
types
are
ones
that
I
accept
and
the
cert
the
server
it's
up
to
the
server,
whether
it
returns
all
of
them
or
some
of
them
or
whatever
I
it.
Anything
else
gets
more
complicated
and
Michael's
already
saying
that
he
doesn't
want
to
complicate
this
anymore.
G
E
G
Sounds
like
you're
converging
on
a
media
type
except
list.
I
mean
I
mean
that
that
makes
the
most
sense,
because
then
I
can
say
as
a
client
I'll
take
any
of
these
things.
You
as
a
server
can
say
here's
what
I
got
that
works
and
whether
that's
a
fuzzy
image,
whether
that's
a
you,
know,
a
shortened
text,
whatever
it
is
at
least
now.
G
D
C
E
Here's
my
big
concern,
though:
what
is
what
nice
that
was
fuzzy
has
a
very
defined
return
value
right.
It's
a
text!
It's
this
many
characters.
It's
in
this,
this
character
set
right.
So
we
have-
and
what's
nice
about
this
and
what's
very
important
about
us,
at
least
with
my
server
hat
on.
We
cannot
be
creating
multiple
previews
for
different
clients.
If
a
client
sends
I
want
a
JPEG
of
10
kilobytes,
and
somebody
said
that
JPEG
of
20
to
life,
that's
not
going
to
work.
E
D
E
Yeah
I
mean
getting
back
to
the
original
problem
we
were
trying
to
solve
was
every
climate
every
climate.
That's
too
broad
of
a
statement.
Almost
every
client
these
days
has
some
sort
of
preview
textual
preview
right,
and
that
was
really
what
we
was
the
initial
impetus
for
this,
and
then
we
added
the
extension
mechanism
because
we
did
have
these
potential
ideas
in
the
future
and
we
didn't
want
to
have
to
come
back.
E
F
Kneel
again,
I,
just
briefly
I
think
the
consensus
in
the
room
is
that,
yes,
the
the
algorithm
is
not
the
right
approach
for
this.
It
should
be
a
except
media
type
and
they
current
spec,
which,
before
we
had
extensions,
is
just
if
you
sent
explain,
you'll,
get
back
a
preview,
there's
no
more
control
from
the
client.
If
they
can't
say
how
long
it
is
or
anything
else
how
you
do
it
or
whatever
just
give
me
a
text
plain
preview
and
the
server
goes.
F
Here's
a
text
plain
preview,
because
I
suspect
almost
every
way
it's
gonna
be
infant.
It
like
certainly
a
fast
mail.
We
pre
case
these
you're,
not
gonna,
get
some
in
different
based.
What
you
ask
there's
only
one
thing:
we're
gonna
return:
you
gmail
is
the
same.
There's
just
no
point
in
adding
more
complexity
than
that.
G
This
is
Peter
given
Michael's
vertical
up
and
down
with
his
head,
died,
I,
I'm,
not
sure,
there's
anything
else
to
say.
Are
you
okay
with
the
idea
that
this
gets
redefined
as
media
type,
but
really
the
only
media
type
that
is
ever
gonna
be
used
in
this
first
go-around
is
to
explain,
and
that
is
equivalent
to
what
is
currently
in
the
document
is
fuzzy
yeah.
E
G
Media
type
right
I
mean
that
what
this
changes
things
to
is
that
the
extension
mechanism
is
no
longer
an
algorithm.
The
extension
mechanism
is
a
media
type,
and
the
first
go-round
of
definition
of
the
document
should
be.
The
only
thing
you
can
do
is
text
plane
and
the
server
will
give
you
a
short
one
and
and
because
that's
what
fuzzy
meant
anyway
right
is
that?
E
I'm
trying
to
say
the
only
thing
I
would
be
a
bit
worried
about
is,
if
we
have
like,
if
the,
if
the
name
of
this
algorithm
now
or
the
name
of
the
return
type
is
text,
claim
that
text
plane
does
have
some
semantics
behind
the
right.
It's
not
just
any
text
plane
of
anybody
of
any
length
I
mean
we
still
have
to
have
those
women
I
will
fight
for
that
one.
We
have
to
have
those
limitations.
E
F
B
C
Don't
know
that
we
need
that
we
have
things
you
can
have
text
HTML,
you
can
have
text
markup,
you
can
have
various
the
things
with
pluses
on
them
to
give
text.
You
know
banana
plus
JSON
and
there's
a
lot
of
options,
and
if
we
just
set
it
up
so
that
it
can
be
extended
with
different
media
types,
then
it
makes
it
easy
and
you
could
even
put
something
in
the
document
that
says
in
the
future.
We
may
extend
this
with
non
text.
B
E
C
B
G
It's
beat
so,
do
we
actually
envision
a
time
where
the
server
really
wants
to
explain
to
the
client
what
previews
it
has,
or
is
this
really
eventually
going
to
be
the
clients
going
to
express
that
it
can
support
more
than
one
preview
and
the
server
is
going
to
give
what
it
is,
in
which
case
the
capability
is
preview?
Do.
E
C
I,
don't
know
that
that's
I
understand,
like
yeah.
Clients
are
happy
to
be
chatty
at
all
times
as
peek
at
that
you
would
really
never
encounter
a
client
that
that
doesn't
want
a
text
preview.
It
may
want
other
things
as
well,
but
I
really
doubt
the
use
case
that
they
wouldn't
want
a
text
preview.
So
the
client
would
just
say:
I'll
accept
text
and
I'll
accept
JPEG
and
if
it
only
gets
JPEG
that's
fine
and
if
it
only
gets
text,
that's
fine
or
it
gets
both.
C
That's
also
fine,
so
yeah
I'm
happy
to
just
advertise
preview,
and
then
we
say
the
media
types
that
are
supported
now
our
text
slash
whatever
and
if
we
just
want
to
say
text
plain:
that's
fine!
If
you
want
to
add
text
any
kind
of
text,
I'm,
okay
with
that
and
then
say
something
about
future
implement
or
future
extensions,
might
support
non
text,
media
types
and
I
think
that
makes
everybody
happy
or
at.
D
C
E
I
think
so
what
I'm
hearing
is
is
the
actual
behavior.
Everybody
agrees
with
the
Klan
behavior
we're
just
going
to
change
we're
gonna,
get
rid
of
the
concept
of
algorithms
and
couch
everything
in
terms
of
media
types
and
then
obviously
we
need
to
change
the
syntax.
For
that.
We're
not
changing.
Anything
in
the
capabilities
is
what
I
was
hearing
well.
C
D
B
D
B
D
D
D
C
D
Everything
taken
out
so
I
think
that's
soon,
yeah!
That's
fine!
Fine!
Okay!
So
we
have
action
item
to
take
this
out.
Yep
I
think
there
are
like
one
remaining
comment
from
aren't
about
search
new
I.
Think
we
had
discussion
was
Braun
and
aren't
about
the
best
behavior
I
think
suggestion
is
keep
search
new,
but
just
make
it
return.
Nothing.
D
B
D
For
the
most
part,
well,
my
philosophy
was
to
try
to
make
it
as
easy
for
the
client
to
do
as
in
climb
that
already
do
various
extensions
or
just
implement
a
map
for
everyone.
They
pretty
much
wouldn't
require
any
changes
taking
out
well,
I
suppose,
if
we're
taking
out
our
apps
here,
two
attacks
we
might
as
well
take
out
new
but
I.
Think.
C
D
C
Which
is
incompatible,
yeah
I,
think
right.
We
should
avoid
changes
where
the
same
thing
works
differently
right,
because
then,
then
we
will
break
compatibility,
but
we
ought
to
make
it
easy
for
a
server
to
support
both
and
then
that's
the
transition
and
now
at
some
point
maybe
the
server's
don't
support
rev
one
anymore,
but
I
think
that
probably
will
never
happen.
C
C
And
that
answer
is
I
was
going
to
go
back
to
the
removed
L
sub
added,
extended
list
line
and
say
that
if
you're
reviewing
this
realize
that
the
addition
of
extended
list
isn't
finished
yet
I
I
I
did
that,
but
there's
more
I
need
to
do
with
it,
and
part
of
it
is
getting
rid
of
the
floppy
text
in
there
that
we
used
to
have
I
would
say
it's
conceptually
finish.
It's
like.
C
D
D
There
are
a
few
things
explaining
body
structure
more
I
think
that's
a
useful
thing
to
do.
This
is
just
because
there
aren't
enough
examples
and
it's
a
at
least
for
me.
It's
a
constant
side
of
errors.
Yep
I
caught
it,
both
server-side
and
client-side.
Every
time
I
do
a
change
in
the
client-side
I.
Don't
actually
remember
how
it
works
so
I
test
against
the
live
servers
to
see
what
the
exact
behavior
is.
So
this
really
needs
no
examples.
D
Another
change
that
Chris
Newman
requested,
and
actually
it
does
much.
My
implementation
extended
list
lost
multiple
match
pattern,
which
I
thought
was
very
cute
idea
at
the
time.
I,
don't
think
anybody
implemented
it
because
well,
the
problem
was
list
is
requirements
on
list?
Is
their
server,
doesn't
return
information
for
the
same
mailbox
twice
or
more
than
once,
where
multiple
patterns
would
require,
keeping
all
the
lists
and
aggregating
them
before
emitting,
as
opposed
to
just
emitting
the
list,
as
you
as
you
go
through
the
mailbox,
so
I
think
this
is
relatively
straightforward.
D
Is
a
backward
compatible
change
as
in
if
you
implement
list
extended
extension
proper,
you
will
support
multiple
pattern,
but
this
will
be
just
like
drivel
case
over
done
fit
in
in
even
parents,
just
a
single,
much
thing
I,
the
next
one
which
I
forgot
about
I,
think
status
in
list
is
seems
to
be
quite
a
favorite.
A
list
return
status
is
nice.
Yes,
so
let's
include
this.
D
D
Content
transfer
encoding
is
working
because
of
the
recursive
nature.
I
think
there
might
be
a
slight
problem
there
for
this
for
AI,
so
my
need
clarification
or
decision
what,
whether
it's
a
special
case
or
we
don't
care
Chris,
Newman,
requested
search
to
be
intelligent
and
I.
Think
Timo
as
well
are
basically
not
necessarily
substring
matching,
but
more
index
type
matching
I.
D
This
is
fine,
except
if
we're
doing
a
search
for
header
fields,
values
I,
think
having
substring
matching
is
actually
preferred.
So
I
would
like
to
discuss
this
a
bit
more
on
a
mailing
list
in
a
sense.
So
if
we
are
doing
full
body
search,
it's
fine
to
do
indexing
and
matching
of
similar
looking
words
or
words
from
different
roots
in
language.
That's
fine!
But
if
example,
if
I'm
searching
for
multi-part
report
content
type
value,
I
don't
want
to
match
it.
Multi-Part
reporting
I
wanted
too
much.
D
D
B
D
D
F
C
B
C
The
service
should
be
able
to
support
rev
one
and
riveted
together
without
having
a
lot
of
changes
in
between
without
having
to
know
the
difference.
So
what
he's
saying
is
that,
if
your
server
today
on
rev
one
just
does
a
fuzzy
search,
when
you
ask
for
non
fuzzy,
we
don't
want
to
have
to
change
that.
We
don't
want
it
to
have
to
have
different
behavior
depending
on
what
the
client
is
again.
D
C
D
D
C
F
C
C
E
D
C
C
D
G
C
Revlon
behavior,
which
is
what
you
define
whatever
this,
which
is
whatever
the
server
does
with
that
search.
Now
there
certainly
can
be
a
recommendation
in
there
that
the
search
for
any
header
fields
that
are
not
freeform
text
better,
not
be
fuzzy
by
default,
as
well
as
kind
of
field.
You
don't
recognize.
G
C
And
for
the
most
part,
that's
okay,
there,
most
searches
that
are
at
least
searches
that
are
generated
by
the
end
user.
Do
they
work
the
way
they
work?
The
user
gets
what
the
user
gets
and
they've
always
sometimes
the
user
gets
annoyed.
I
get
annoyed
right
now
from
Outlook
because
it
does
not
filter
my
messages.
The
way
I
want
them
to
and
I,
don't
know
why,
but
there
it
is.
But
you
know.
F
F
C
D
C
D
C
B
C
D
Right
this,
this
is
the
slide
which
I
presented
last
time
and
unfortunately,
I
don't
remember,
answer
to
aid
of
these
questions.
So
one
question
was
whether
we
want
to
fold
in
search
for
us,
which
is
basically
allow
allow
you
to
pipeline
several
commands
by
saying
search
for
this.
Do
this
with
the
results
like
copy,
you
know,
move
there
I.
B
D
People
happy
to
include
this
yes
last
chance.
Okay,
we'll
do
that,
and
the
second
part
is
state
is
deleted,
which
is
number
of
messages
with
deleted
flag.
The
use
case
for
this
is
quota
type
thing.
If
you
know,
if
you
know
box
is
getting
close
to
quarter,
if
you
know
expunge
it,
this
is
how
much
you
can
regain
I.
D
D
D
Some
such
related
changes
as
discussed
I'll
go
over
and
Barry
over
comments
from
Timur
and
aren't
make
sure
that
they
all
address
some
of
them.
I
think
most
of
them
were
accepted.
Some
of
them
were
rejected
in
some
cases
is
probably
just
replying
to
Jemma
saying
no,
we
decided
not
to
do
this
because
so
just
to
get
done
and
I
would
really
like
to
do
working
last
call
before
Christmas
all
right.
D
B
I
am
hesitate
to
raise
it,
but
I
would
love
to
say:
okay,
kai
they
go
in
I,
know
it's
we've
gone
backwards
and
forwards.
On
this
a
few
times,
I
had
an
interesting
chat
with
the
Gmail
API
team
recently
in
which
there
came
to
do
it.
So
if
it
seems
most
servers
have
some
kind
of
unique
IDs
for
objects
internally
for
mailboxes
and
for
messages.
D
B
D
B
C
B
D
B
D
B
B
D
B
D
Yeah,
basically,
the
problem
with
the
original
spec
it
was
under
specified.
It
was
making
certain
things.
It
made
everything
an
example
yeah
we're
now
we
are
creating
a
registry
of
these
I
think
there
are
like
two
or
three
things
which
are
more
likely
to
be
implemented.
As
long
as
you
know,
it's
easy
to
add
to
the
register
on
the
ID
I
mean.
B
B
D
D
D
B
B
D
D
D
C
B
B
D
B
B
D
H
D
Duke
very
quick
last
call
on
the
updated
syntax.
Once
we
see
it,
cool
with
that
is
G.
I
can
just
say:
look
this
thing
changed
to
that
thing.
Do
people
care
or
you
just
trust
us
that
it's
fine,
yeah
and
see
because
not
nobody
other
than
Barry
have
any
serious
comments
on
the
document
anyway.
So
but
I
will
ask
for
IG.