►
From YouTube: IETF100-DISPATCH-20171113-0930
Description
DISPATCH meeting session at IETF100
2017/11/13 0930
https://datatracker.ietf.org/meeting/100/proceedings/
B
A
A
C
A
B
A
Please
note
the
note
well:
well,
the
RFC
and
BCP
numbers
on
here
may
actually
be
a
bit
stale.
This
is
a
recycled
slide.
I
will
update
them
after
this
meeting,
but
the
slide
identifies
your
rights
and
obligations
with
respect
to
intellectual
property
and
contributions
within
the
IHF.
My
condensed
slide,
you
have
the
right
to
remain
silent,
etc,
etc.
Anything
you
say
contribute
is
a
contribution
of
the
ITF.
Please
read
those
prior
BCPs
and
rfcs.
A
If
you
have
any
questions
about
this
so
beginning,
The
Dispatch
part
of
this
meeting,
the
deadlines
for
ITF
101,
we
have
standard
rotating
deadlines
about
how
to
get
yourself
on
the
agenda,
how
to
get
things
appropriate
attention
if
they're
being
dispatched.
These
are
the
deadlines
that
I
backtracked
from
based
on
what
the
date
of
the
IAT
F
next
IETF
meeting
they
may
be
slightly
off
by
a
day
or
two
I
may
have
accounted
incorrectly
in
my
jet
lag
nature
last
night,
but
please
aim
for
these.
A
If
you
have
work
that
you
want
to
have
dispatched
discuss
at
IETF
101,
the
general
purpose
of
these
deadlines
is,
if
you
make
the
deadlines,
you
will
get
at
end
of
time,
pretty
much
guaranteed
unless
there's
huge
competition
for
it,
which
is
uncommon
if
you
miss
the
deadlines
you're
behind
the
any
other
business
turn
in
terms
of
priority.
Please
start
your
draft
names
as
normal,
with
draft
your
last
name
and
dispatch.
So
that
way
they
are
associated
with
this
working
group,
even
if
even
prior
to
them
being
accepted
as
working
group
items
or
being
dispatched.
A
A
A
So
this
is
a
the
name
of
a
draft
that
was
posted
recently
to
the
dispatch
list.
It
introduces
a
compression
technology
that
we
are
seeking
to
have
published
as
an
informational
document
and
registers,
a
media
type
and
a
content
encoding
for
it.
It
is
the
processing
path
we're
looking
here
is
for
here
is
very
similar
to
the
way
broadly
did
it,
which
is
to
describe
the
format
register
the
code
points
and
pretty
much.
That's
all.
A
A
D
E
A
What
is
this
useful
for?
It's
probably
the
same
thing
that
Jesus
and
Bradley
would
be
used
for,
except
for
we
don't
have
broadly,
is
very
much
geared
toward
browser
space.
We
are.
We
have
different
applications
in
mind
like
the
Linux
kernel
is
using
it.
So
there
are,
there
are
other
application
spaces
where
it's
potentially
useful,
so.
A
A
F
Yeah
Alexei
Melnikov
I
think
once
upon
a
time
we
were
registering
contenttransfer
encodings,
at
least
for
email
and
other
places
right
were
they
still
used.
I
think
what
I
remember
from
that
talking
about
it
is
that
it's
very
hard
to
actually
add
content
transfer
encoding
as
opposed
to
media
types
to
various
and
systems.
That's
why
we
basically
sort
of
stopped
doing
this
I'm
sitting,
except
for
very
specialized
cases.
That's
coming
back
the
Y
media
type
might
be
here.
Oh,
oh
I,
see
possible.
You
know,
need.
F
A
A
D
F
B
F
Just
a
very
quick:
no,
there
isn't
much
general
update
from
us
as
far
as
I
know,
but
we
have
this
new
art,
art
Directorate,
for
reviewing
documents
which
doesn't
have
many
very
many
members,
but
it
was
actually
we
sort
of
trying
it
out
and
it
was
quite
useful
in
the
last
six
months
or
so
our
we
had
some
reviewers
who
done
more
than
others
and
in
particular
Martin
Thompson
and
reviewed
three
documents
and
Mark
Nottingham
reviewed
two
documents,
and
this
was
very
helpful
to
RT
AG's.
So
RT
G's
would
like
to
thank
all
the
reviewers.
F
B
F
A
F
A
B
A
We
normally
enumerate
the
buffs
that
are
scheduled
for
the
week,
my
neglected
to
actually
invite
the
chairs
to
talk
about
it.
So
these
are
the
four.
If
anybody
wants
to
say
something
in
the
mic
about
what
they
are,
why
we're
interested
in
when
they
are
please
head
up,
but
since
we
didn't
actually
invite
anyone
I
don't
actually
expect
that
and
the
two
working
groups
that
are
chartered
since
then
DOE
and
extra
the
extra
chair
is
here.
A
B
A
C
C
C
We've
got
organizations
that
are
starting
more
and
more
to
use
mobile
messaging
to
send
various
kinds
of
notifications,
and
some
of
these
are
notifications
that
can
be
fairly
security,
sensitive
so,
for
example,
financial
transactions,
a
notices
or
password
change,
notices
or
any
number
of
other
kinds
of
things
that
if
they
were
falsified,
King
calls
problems
and
you
can
see
there's
a
number
of
ways.
These
can
fail.
I
think
that's
pretty
obvious
next
slide,
believe
it
or
not.
There
are
still
people
that
care
about
messaging
applications
in
the
simple
environment.
C
I
know
it's
easy
for
us
to
say
that
you
know.
No
one
really
cares
about
interoperable
messaging
anymore,
but
there
are
some
ecosystems
that
are
using
this,
for
example,
of
vaulty
doing
SMS
over
multi
uses
that
message
and
then
there's
this
RCS
thing
that
a
lot
of
operators,
mobile
operators
still
care
about
which
uses
both
set
messaging
and
MSRP,
and
for
the
use
case
that
we
were
that
I
just
mentioned
signed
messaging
is
kind
of
your
low-hanging
fruit
and
that's
because
it
doesn't
really
the
client
certificate
problem.
C
C
C
We
also
have
some
suggestions
about
putting
sip
view
our
eyes
in
the
subject:
alternative
names
in
certificates
so
because
that's
the
identity,
that's
typically
going
to
be
you're,
going
to
need
a
match
to
and
you're
dealing
with,
both
sip
and
MSRP
and
and
actually,
very
importantly,
whatever
you
do-
don't
put
MSRP,
URLs
and
they're
that
useless
for
that
purpose.
Next
slide,
we've
got
some
general
stuff
about
how
user
agents
can
express
what
kind
of
s-line
capabilities
they
have.
C
This
is
primarily
through
the
use
of
identifying
what
mime
types
they
can
handle,
and
this
is
not
entirely
satisfactory
in
some
areas.
For
example,
sip
forking
makes
it
difficult
to
know
for
sure
that
the
user
agent
that
you're
hitting
it's
a
user
agent
that
you
might
think
you
know
it's
capabilities.
Some
other
saying,
sip
message
has
very
tight
size
limits
and
we
start
talking
about
any
kind
of
complex
messaging.
C
So
we
need
to
keep
those
messages
small
and
for
actually
for
both
sip
and
MSRP,
the
SIP
and
their
respective
specs
assume
that
decryption
is
happening
immediately.
When
you
deliver
things
so
they
make
some
requirements
around
4:15
and
493
responses
that
may
not
make
sense
in
a
world
where
encryption
may
not
happen
until
you've
got
user
eyeballs
on
the
mess
which
made
the
minutes
or
hours
after
the
message
was
sent
to
the
user
agent
for
MSRP.
C
C
So
there
are
some
issues
to
think
about
in
these
general
ecosystems,
and
some
of
these
are
really
questions
about
what
people
care
about
and
what
is
actually
out
there
deployed.
So
if
people
remember
CPM,
let's
deepen
our
history
of
of
rise.
Treatment
of
messaging
allows
us
to
add
metadata
into
messaging
in
addition
to
what
metadata
might
be
in
the
SIP,
MSRP
headers,
and
so
an
open
question
is:
do
we
care
about
that?
There
may
be
some
use
cases
for
word.
C
There
might
other
be
some
other
applications
of
throwing
in
various
other
pieces
of
metadata
that
we
want
to
be
attached
to
the
signatures.
There
may
be
some
interactions
with
IMD
n.
That
would
be
the
instant
messaging
delivery
notifications
somehow
or
another
we
met.
Let
the
I
in
I
be
sorry
the
IMD
M
spikes
get
by
to
explicitly
allow
application
servers
to
modify
CPM,
headers
and
existing
messages.
C
C
The
draft
days
examples
and,
as
almost
always
a
case
was
a
0-0
I'm
sure
the
security
considerations
need
some
expansions
next,
please
so
really
at
this
point,
we
like
to
draw
people's
attention
to
it,
get
feedback
on
it.
We've
had
a
few
comments
on
the
list
and
my
question
is:
do
people
think
subject
space
is
worth
working
on
and
if
they
do
so,
how
should
we
move
forward
with
it?
And
my
comments
on
this,
like
I,
said
that
this
seems
like
overkill
for
a
working
group.
Well,.
C
B
B
B
C
H
Right,
yeah,
yeah,
Sean's,
first
hi,
Sean
Leonard,
so
overall
I
read
the
draft
and
I
want
to
speak
generally
in
favor
of
it.
I
think
that
it
should
move
forward
the
process
that
it
goes
through.
I
don't
have
a
strong
opinion
on,
and
the
only
thing
I'd
say
is
within
the
context
of
all
the
other
IETF
related
work
around
secure,
messaging
or
whatever
that
it
just
specified
the
version,
a
best
mime,
which
would
probably
version
4.
Since
that's
what's
currently
being
worked
on
to
minimize
interoperability,
testing
headaches
but
generally
I'm
in
favor.
D
C
D
C
D
That's
kind
of
where
I
was
going
if
you're,
if
you're,
actually
attempting
to
do
anything
meaningful
here,
you
kind
of
need
to
tackle
that
problem,
and
so
that
sort
of
leads
me
to
the
conclusion
that
overkill
is
probably
a
not
even
close
to
right.
It's
the
opposite!
If
you
don't
do
a
working
group,
you're
not
going
to
give
this
the
attention
that
it
actually
deserves.
Okay,.
J
Hey
John
Peterson,
so
probably
unsurprisingly,
my
question
about
this
is
why
you
want
to
do
this
with
s/mime
instead
start
in
general,
and
there
are
at
least
three
I
think
good
reason
to
say
that
one
is
one
of
the
reasons
we
end
up
doing
stir
in
the
first
place,
because
nobody
did
that's
mine
right.
It's
not
like.
We
didn't
try
to
put
s
climb
into
3261.
We
did
try
to
patch
it
like
15
times.
Didn't
do
that
AIB.
What
was
that
again?
J
The
authenticated
identity
body
thing
right
to
try
to
minimize
the
things
you'd
be
signing
with.
That's
fine
go
to
a
seafoam
approach,
so
I
mean
we
reran
that
code
and
number
of
times
when
I
looked
at
what
your
use
cases
were
for
this,
which
are
things
like
SMA,
which
are
things
like
bolte.
Those
are
endpoints
of
telephone
numbers.
They're
gonna
want
all
the
certificate
infrastructure
that
stirrers
created
for
that,
and
if
you
want
to
do
cryptography
with
that
as
well,
in
addition
to
decide
entity
I'm
afraid,
sip
brandy
is
probably
your
best
bet.
J
C
So,
first
of
all,
thank
you
for
asking
that
question.
You
checked
one
of
my
check
boxes
in
my
discussions
with
Russ
about
what
our
questions
were
going
to
be:
okay
and
and
right
now
the
the
counter-argument
for
that
is
that
in
these
particular
ecosystems
the
code
already
exists
and
a
lot
of
user
agents
to
handle
s/mime
or
at
least
only
platforms
around
to
handle
s/mime,
for
other
reasons,
they're
doing
it
in
their
mail
packages
there.
C
So
that's
sort
of
saying,
while
going
with
a
JWT,
jws
sort
of
approach,
I
think
it's
very
interesting
and
I
don't
think
any
work
here
should
prevent
doing
that
work,
but
I
think
that
that
is
going
to
require
more
greenfield
coding
on
the
clients
than
an
SVM
approach.
Might
right
now
for
what
I
see
happening.
Stirrer
I
think
that
eventually
you're
going
to
have
three
validations
demo
clients,
but
maybe
that
right
away
so.
J
K
Krista
Homburg
I'm
proxying,
for
my
for
my
colleagues,
working
with
RCS
and
and
I
get
one
question
and
one
comment.
The
question
is
whether
this
excludes
direct
peer-to-peer
messaging
between
two
endpoints.
If
there's
a
reason
why
it
wouldn't
work
for
that,
I
don't
know
if
that's
related
to
what
Martin
was
asking,
and
the
comment
is
on.
Maybe
it's
too
detailed
to
discuss
here,
but
I'll
give
it
anyway.
It's
on
the
C
team.
K
The
draft
says
that
most
of
the
time
or
typically
the
whole
CPM
body
is,
is
encrypted,
but
the
headers
can't
be
encrypted
in
a
lot
of
use
cases
because
their
use
case
for
this
like
store-and-forward
later,
and
things
like
that,
where
you
need
this
information,
so
you
can't
really
encrypt
it.
I
don't
really
know
if
that's,
maybe
that's
just
a
detail
but
but
just
to
make
sure
it's.
There
is
not,
as
that
you're,
don't
assume
the
whole
thing
to
be
encrypted
for
this
to
work.
That's
okay,.
C
Actually,
thank
you
for
that
comment.
That's
that's
kind
of
why
I
have
CPM
listed
as
a
we
need
more.
Do
we
need
more
discussion
here
and
I
think
you're
suggesting
we
do
and
how
that's
gonna
fall
out.
It's
not
immediately
obvious
I'm
trying
to
back
up
to
your
first
comment
and
I
actually
fell
out
of
my
head.
Can
you
repeat
the
first
part
of
your
coming
again.
C
Well,
we
don't
want
discount
encryption,
but
a
encrypted
model
or
a
cryptid
messaging
or
a
user
signed
messaging
is
harder
because
of
the
kita
stiffly
distribution
issues,
and
this
draft
has
not
attacked
that
problem
at
all.
But
I
recognize
it's
a
problem.
We're
thinking
about
a
regular
peak,
regular
public
key
infrastructures
can
deal
more
with
the
organization
to
users.
Well,
if
we're
going
to
talk
about
anything
involving
end-user
certificates,
then
we
need
to
think
more
about
how
we're
gonna
handle
that.
L
Andrew
Allen
I
had
sort
of
a
similar
saw
reaction,
I
guess
to
John
on
this
with
YS
mime
I
mean
to
my
knowledge
that
doesn't
seem
to
be
a
lot
of
implementations
out
there.
Lisa
wasn't
two
years
ago,
when
this
issue
came
up
in
free
GBP,
I
looked
at
least
at
sip.
It
I
looked
at
all
the
separate
results.
It
was
hardly
any
s/mime
implementations
that
were
showing
up
at
so
there
at
least
a
few
years
ago,
and
so,
if
the
use
case
here
is
commercial
carriers,
I'm
not
sure.
L
If
this
is
something
that's
they're
going
to
use
and
maybe
them
it
may
be
worth
looking
at
different
different
security
mechanisms.
Maybe
there
should
be
a
general
framework
or
considerations
and
then,
like
particular,
four
particular
security
mechanisms.
I,
don't
want
to
get
Goods,
at
least
at
least
in
3gpp
right
now
on
no
one's
using
yes,
mine,
I
think.
M
C
Without
diving
into
that
and
probably
need
a
time
check,
but
without
diving
into
into
the
technical
details,
I
don't
think
doing.
One
precludes
doing
the
other
there's
a
question
about
the
what
resources
we
will
put
on
there,
but
I
think
there
is
and
I
think
it's
worth
more
discussion.
I
think
there
is
a
constituency
for
doing
this
in
s
mind,
which
is
a
sufficient
reason
to
do
it.
That
doesn't
mean
this.
Mine
is
the
best
solution
for
everything
for
the
world
and
I
certainly
would
love
to
see
work
done.
A
A
B
D
D
It
seems
like
we
have
people
interested
in
having
the
work
done,
I'm
interested
in
seeing
the
work
done
if
it
were
possible,
but
do
we
actually
have
enough
thrust
to
get
it
over
the
line
and
I'm
not
sure
what
the
answer
is
on
that
one
I'd
like
to
see
a
little
more
work
on
it.
My
perhaps
right
but
and.
C
It
can
I
make
a
quick
scope.
Comment
too.
I
think
the
idea
of
attacking
secure
messaging
would
be
a
wonderful
thing
for
us
to
do.
I,
don't
know
if
it's
a
practical
thing
for
us
to
do
that.
Wasn't
really
the
intent
of
this
draft
by
itself.
This
draft
was
to
clarify
some
usage
issues
around
the
use
of
s
mine,
because
we
believe,
as
Martin
pointed
out,
that
there
is
at
least
some
community
that
would
like
to
use
as
mine
in
a
mobile
messaging
type
environment.
So.
C
A
I
got
to
say
two
things:
the
first
is
if
we
do
decide
to
move
forward
with
this
I'm
happy
to
work
with
ban
on
the
Charter
things,
but
I
think
we're
kind
of
hopping
over
the
question
of
who
would
be
like
willing
to
work
on
this.
That's
what
I
would
like
to
see
a
show
of
hands
before
we
even
talk
about
it.
You
know
about
whether
we're
moving
this
into
a
working
group
or
disposition
in
any
other
way.
Okay,
who
in
the
room,
would
work
on
this
if
a
bus,
Stevens
interrupting
I'm.
A
C
That
some
do
exist
on
the
male
side
and
whether
or
not
code
that's
in
mail
applications
can't
own
own.
Mobile
platforms
can
be
turned
around
I
used
in
the
messaging
application.
I
have
no
clue
about.
For
example,
you
know
the
mail
app
in
in
a
iOS
is:
can
handle
s/mime,
usually
typically
in
enterprise
situations,
where
you're
using
the
enterprise
management
functions
to
control
your
certificates.
J
So
John
Peterson,
so
yeah
I,
mean
I,
think
secure
messaging
thing
is
worth
us
doing
and
being
right
about.
I
would
kind
of
I
would
kind
of
look
at
that,
though.
As
a
very
separate
thing,
then,
let's
make
these
tweets
to
a
spine,
so
it
like
the
you
know,
the
544,
50
and
so
on.
Work
works
right
right.
J
Who
are
you
that
I'm
not
terribly
interested
to
be
on
this
day
I
know,
I
wrote
a
lot
that
s
mine
stuff
back
in
the
day,
so
I
mean
maybe
partially
my
fault
that
it's
messed
up,
but
the
same
time.
I,
don't
think
I
would
invest
a
lot
of
energy
into
that.
If
there
was
a
secure
messaging
thing,
though,
I
want
a
problem
statement,
and
you
know
for
us
to
talk
about
what
the
right
way
is
to
do
something
messaging,
I'm,
sad,
because
I'm
not
convinced
that
this
is
the
right
overall
approach
to
that.
J
C
Okay,
so
to
avoid
accidentally
buffing,
secure,
messaging,
I
think
the
question
and
let
the
chair
is
again.
My
ET
hat
is
not
on,
but
as
a
individual
contributor.
My
question
is
around:
who
would
help
progress,
work
on
clarifying
the
use
of
s
9
and
sip,
and
MSRP
potentially
doing
more
work
around
that,
like
some
key
management
stuff,
although
that's
not
in
the
draft
and
I,
don't
know
if
that's
good,
for
that's
something
we
need
to
do
is
a
question.
I
think
is
very
interesting
to
me.
C
P
Hi
I'm
Jim
Fenton
I'm,
some
of
the
use
I
apologize
for
coming
in
the
middle
of
this
and
missing
some
of
it.
But
some
of
the
use
cases
that
were
mentioned
things
like
password,
resets
and
financial
notifications
are
things
that
I
I,
don't
think
you
know
we
tend
to
use
email
for
them
a
lot
and-
and
it's
a
very
bad
solution
to
that.
P
But
I
think
that
there's
enough
there
that
we
should
be
looking
more
broadly
at
at
how
we
do
it,
assuming
that
we
want
to
do
it
necessarily
with
sip
or
MSRP
or
s/mime
I,
think
we
need
to
kind
of
step
back
from
it
a
little
bit
and
look
at
the
overall
requirements
for
what
would
be
a
good
medium
in
order
to
convey
that
that
kind
of
notification
and
figure
out
what
the
best
way
to
do
it
is
I'm,
not
convinced
that
any
of
the
technologies
that
we're
talking
about
here
are
necessarily
the
right
answer.
Okay,.
M
C
It
seems
to
me
is
be
the
worst
of
all
possible
worlds
to
be
used
for
that,
but
that's
they
use
that
because
that's
what
gets
to
their
users
reliably
and
when
they
start
looking
at
other
approaches
to
this,
they
can't
assume
that
all
their
users
can
get
it.
What
he
might
exist
right
now
there
a
lot
of
people.
A
lot
of
organizations
are
using
smartphone
apps
for
similar
purposes,
which,
depending
on
the
smartphone
app,
might
be
great,
it
might
be
awful
who
knows.
C
The
community,
particularly
some
of
the
u.s.
mobile
community,
that
Martin
mentioned,
is
acutely
worried
about
this,
and
that's
why
they're
looking
specifically
at
ways
to
move
into
a
more
secure
mobile
messaging
type
environment,
getting
everyone
to
agree
on
better
technologies
to
use
for
this
kind
of.
P
Just
as
a
for
instance,
of
the
sort
of
thing
that
that
what
we
currently
have
doesn't
work
is
the
notifier
doesn't
have
any
way
of
knowing
that
the
message
actually
got
there.
It
tends
to
be
sort
of
fire-and-forget
and
for
things
like
a
notification
that
you
know,
there's
been
a
big
financial
transaction
or
something
like
that.
The
bank
might
want
to
know
that
the
you
act
that
message
was
actually
delivered.
Some
of
the
some
of
the
things
that
have
come
along
since,
like
iMessage,
give
you
some
of
that.
P
Q
J
About
that,
if
again
from
the
scoping
perspective,
if
the
cert
management
component,
this
becomes
then
again
I
think
that
gets
much
much
more
interesting
right
and
like
there
are
things
that
I
think
evolved
from.
What's
going
back
me
what's
going
on
stir
and
so
on
that,
if
you
weren't
doing
it
that
way
again,
I
think
you
I
would
probably
want
to
run,
have
fun
cats
so
we'll.
K
Kirsta,
this
is
more
a
general
comment.
I
think
if
there
are
people
who
want
to
use
this
and
if
we
think
there's
something
regarding
to
the
usage
that
need
to
be
clarified
or
maybe
updated,
because
and
so
on,
I
think
we
should
do
it.
I
mean
this
is
the
reasons
why
I
and
others,
for
example,
in
in
city
core.
We
have
a
lot
of
problems
with
session
time
and
so
on,
because
it's
actually
something
that
people
are
deploying
and
sooner
or
later,
you're
gonna
start
getting
this.
K
You
know
emails
when
things
don't
work
and
and
if
the
specification
is
unclear,
it's
very
difficult
to
say
whose
fault
it
is
and
so
on.
So
so
so
I
think
if
this
is
something
that
s/mime
is
part
of
three
to
six
one,
so
it's
a
valid
you
know
thing
to
use.
So
so,
if
something
needs
to
be
clarified
and
people
want
to
use
it
I
think
we
should
do
it.
Thank
you.
H
All
right,
Sean,
Leonard
I,
think
that
the
current
draft
in
its
general
scope,
omitting
certificate
management
and
stuff
like
that
is
the
right
approach.
There's
a
lot
of
stuff
that
can
be
done
there,
but
I
think
that
it's
out
of
scope
and
in
point
of
fact,
s/mime
as
a
general
framework,
can
do
a
lot
of
authentication
or
protection
of
content
that
has
nothing
to
do
with
certificates
at
all.
B
I
B
C
Just
one
closing
remarks:
if
you
mentioned
a
problem
statement,
I
agree
that
there's
not
a
clear
problem
statement
in
the
draft
I
can
quick
remark
on
that?
I
think
you
know.
The
core
of
the
problem
statement
is
that
we
believe
that
some
people
that
want
to
do
that's
mine
and
right
now,
the
way
things
have
specified
in
the
existing
specs
it's
hard
to
do
as
mine
and
an
interoperative
way
for
a
messaging
application,
as
opposed
to
say,
moving
STP
around
for
signaling
calls
type
application,
yeah.
B
Q
R
B
S
When
we
talk
about
these
issues,
much
of
the
time,
our
focus
has
been
in
character,
encoding
and
matching.
That's
not
all
of
the
problem,
a
very
broad
set
of
issues.
They
include
data
time
formats
and
time
zones
which
affects
calendaring
data
entry
conventions
which
affects
user
interfaces
and
character,
Pickers
and
input
method
systems
and
operating
system
design.
S
The
effects,
presentation
of
particular
situations,
rendering
a
type
style
selection,
turn
out
to
be
something
very
important
that
the
IETF
has
rather
carefully
avoided,
perhaps
wisely.
It
includes
confusable
characters
and
deceptive
strings.
Something
there's
been
a
great
deal
of
discussion
about
as
a
security
issue.
Among
other
things,
there
language-specific
convention
issues,
we're
always
become
particularly
important.
When
you
don't
know
what
the
language
is,
if,
if
things
are
specific
to
a
language-
and
you
can't
tell
what
the
language
is
you're
in
trouble,
we
have
transition
problems
from
ask
the
only
systems
and
how
we
do.
S
Many
of
the
selected
solutions
look
like.
Let's
have
this
one
and
that
one
at
the
same
time
and
and
that
causes
horrible
complications
more
so
in
some
systems
than
in
others,
unless
there's
broad
consensus
on
what
should
be
a
canonical
form
and
how
to
get
to
it,
and
that
consensus
is
understood
and
accepted
by
end-users.
S
The
simplest
example
for
asking
well
everybody:
well,
there
been
many
claims
in
in
the
last
several
years
that
users
always
expect
case
insensitivity.
We
trained
at
pull
generation
of
users
with
with
UNIX
and
similar
systems
does
not
expect
that
at
all.
So
these
are
often
much
more
complicated
issues
than
we
tend
to
pretend
next
slide.
S
That's
going
to
be
possibly
my
most
controversial
statement
for
today,
but
backing
out
of
AI
DNA
may
be
impossible,
and
if
that
hypothesis
is
correct,
then
the
question
is
how
to
make
the
best
of
a
bad
situation
rather
than
how
we
make
this
perfect
or
wonderful
or
satisfy
everybody
with
AI
DNA.
At
this
point
there
are
many
warts
and
drafts
to
address
address
at
least
partially,
some
of
them
fairly
difficult
and
complicated
ietf
actions.
Last
three
years
have
been
to
do
nothing.
We've
cleared
up
some
crazy
definitional
issues.
S
We've
got
an
IAD
statement
who
I
can
was
just
doing
nothing
until
the
ITF
sorts.
This
out.
That
statement
is
becoming,
at
least
in
some
quarters
more
problematic
over
time
as
more
unicode
versions
released.
We
had
a
ball
called
lucid,
which
went
out
a
few
rat
holes
and-
and
at
least
in
my
opinion,
led
to
nothing
and-
and
we've
made
some
patches
to
allow
some
non
ASCII
domains
and
email
addresses
inserts,
some
of
which
are
now
approved.
S
So
the
immediate
problem
is
that
we've
got
three
drafts
which
are
waiting,
consideration
or
processing
that
are
stuck
one
of
the
minutes.
Predecessors
have
been
stuck
for
two
and
a
half
years
and
that's
the
one
that
stimulated
the
IAB
statement
and
started
off
with
them
with
an
issue
with
an
Arabic
character,
but
has
been
but
clearly
expands
considerably
beyond
that.
S
We've
got
a
draft
as
clarifies
at
the
MS
issue
about
taking
responsibility,
nothing
new
there,
but
the
clarity
of
the
responsibility
may
be
important
and
we've
got
another
draft
about
troublesome
characters,
which
is
one
of
several
possible
attempts
to
work
around
the
issues
rather
than
focusing
on
them
head-on.
Although
again,
this
kind
of
thing
may
be
the
best
we
can
do,
we
just
don't
know.
S
S
It's
probably
symptomatic
of
the
large
number
of
hands
which
way
up
that
people
are
not
interested
in
getting
dragged
into
this
problem
if
they
can
possibly
avoid
it.
That
doesn't
make
the
problem
less
important,
but
we've
heard
in
a
number
of
working
groups,
people
stand
up
and
say
what
I
really
need
is
for
you
to
just
tell
me
what
to
do
so.
S
I,
don't
need
to
understand
this
if
the
people
who
said
that
are
in
the
room,
you
know
who
you
are,
that's
so
a
recipe
or
search
for
recipe,
so
one
can
follow
that
recipe
and
be
safe
and
have
systems,
work
and
work
globally.
Without
anyone
having
to
think
or
understand,
very
much
in
the
process
of
designer
implementation
and
the
bad
news
is,
it
doesn't
work
and
it
doesn't
work
because,
as
we
keep
discovering
every
time,
we
look
in
an
area
of
this
set
of
problems,
we
find
idiosyncrasy.
S
If
it's
good
enough
to
display
the
characters,
then
there
are
things
you
can
do,
but
if
you
want
the
characters
displayed
correctly
or
displayed
the
way
or
displayed
on
receipt,
the
way
the
sender
intends
or
display
the
way,
a
normal
reader
of
that
language
expects
to
see
them
that's
much
harder
than
it
gets
language
specific
and
script
specific
and
what
happens
to
us
when
we
try
to
think
about
a
discuss.
These
issues
is
that
we
keep
getting
a
substrate
into
trivia.
We
fall
into
a
Latin
script
trap.
S
S
So
in
general,
these
expect
extrapolations
from
one
languages
script,
don't
work,
two
languages
of
scripts,
don't
work
much
better,
but
at
the
same
time
the
desire
and
expectation
of
the
community
is
to
just
have
this
problem.
Go
away
with
some
simple,
easily
followed
formula
and
the
bad
news.
No
such
formulas
out
there
next
slide.
S
S
S
This
is,
in
some
respects,
no
worse
than
a
situation
in
which
we
have
lots
of
competing
standards
out
there,
but
every
variation
in
every
competing
standard
creates
a
risk
of
user
confusion,
a
risk
assistance
not
working
as
expected
by
the
users
or
by
the
developers,
including
having
false
negatives
or
positives.
But
that's
not
limited
to
that,
and
every
one
of
these
sources
of
confusion
is
the
fact
is
a
potential
vector
for
an
attack.
S
It's
been
claimed
that
there
are
fewer
of
these
attacks
than
we
might
expect
or
that
we
have
been
claiming,
but
this
is
also
related
to
attackers
very
often
not
needing
to
be
smarter
than
they
have
to
be,
and,
and
that's
a
very
temporary
and
unstable
situation
again.
I
DNA
is
not
the
only
problem
area
here,
but
the
DNS
and
traditional
matching
rules
and
structures
and
assumptions
implies
special
complications.
S
Whatever
we're
doing
now
to
solve
these
problems,
it
isn't
working.
Things
are
getting
worse
unless
we
can
find
another
way.
This
is
this
area's
problem
to
solve.
If
you
think,
knowledge
and
depth
about
this
area
is
bad
here,
go
look
at
security
and
go
look
in
other
areas
about
even
the
questions
about
whether
one
should
internationalize
or
stick
with
ASCII,
as
one
looks
at
identifier,
z'
and
protocol
handshakes,
and
so
on
next
slide.
S
As
far
as
I
know,
we've
discussed
three
groups
of
possibilities
about
how
to
move
forward
with
this.
The
first
most
obvious
is
the
creative
working
group,
but
the
problem
there
is
having
a
critical
mass
of
expert
people,
and
that
means
a
problem
with
leadership
and
a
problem
with
resources,
as
well
as
the
people
themselves.
We're
short
of
the
people
were
short
of.
The
leadership
were
short
of
the
resources.
A
second
possibility
which
has
been
kicked
around
is
to
create
some
sort
of
special
review
team
and
really
empower
it.
S
There's
a
problem
with
how
to
select
membership.
The
question
is
whether
the
iesg
or
the
community
would
accept
the
conclusions.
But
if
this
we're
going
to
work,
we
need
to
move
between,
accept
what
that
group
says
unless
there's
a
counter-argument
or
somebody
raises
a
fuss
to
accept
what
that
group
says
unless
there's
a
solid
grounded
expert
argument
against
it
carries
risks.
S
Another
suggestion
which
has
been
made
is
to
leave
the
problem
to
someone
else.
The
Unicode
consortium
is
the
most
frequent
example,
but
I've
heard
some
suggestions
about
various
ican
groups
as
well.
This
has
a
certain
swell
in
the
past.
It's
one
of
the
sources
of
contradictory
advice
that
we're
dealing
with
that
contradictory,
at
least
if
one
believes
DNS
names
are
identifiers.
S
If
one
believes
that
they
are
simple
expressions
of
thoughts
or
preferences
or
brands,
then
maybe
there
isn't
a
problem
at
all
and
the
Unicode
folks
seem
to
have
problems
deceiving
of
language
independent
identifiers
as
every
so
we've
had
those
discussions
about
specific
problems
that
they
turn
around
and
say.
Well,
there's
no
problem:
cuz
they're
different
languages,
even
if
they're
the
same
script
and
obviously
other
ideas
are
welcome.
But
that's
where
we've
got
me
next
slide.
S
But
as
we
look
at
this
and
move
forward,
remember
that
ignoring
the
issues
and
doing
nothing
creates
risks,
and
the
history
at
least
so
far,
is
that
either
makes
things
get
worse
or
lets
them
get
worse,
and
if
our
job
is
to
make
the
internet
work
better
globally,
then
ignoring
internationalization
is
inconsistent
with
that
goal,
and
we
need
to
figure
out
how
to
do
something
suggestions.
Comments
thanks
very
much.
T
It
occurs
to
me,
leaving
the
problem
to
someone
else
alone
is,
of
course,
not
gonna
work,
and
has
it
traditionally,
but
it
occurs
to
me
that
part
of
the
problem
we've
run
into
with
the
Unicode
consortium
in
particular,
is
that
we
are
running
independent,
whether
it
be
consensus
or
other
sorts
of
decision
processes,
and
they
are
not
required
to
come
to
consensus
themselves.
That
is,
Unicode
consortium
has
a
set
of
desires
about
how
stuff
should
be
used.
Sometimes
we
hear
responses
like
well.
You
should
stop
doing
that.
T
That's
not
how
we
intent
design
this
thing
or
intended
it
for
to
be
used.
We've
asked
questions
like
how
should
we
use
it
properly?
Can
you
guys
do
some
sort
of
identifier
system
since
we're
using
some
of
these
as
identifiers
x'?
That
turns
out
to
be
problematic?
I'm
wondering
if
one
of
the
solutions
is
to
figure
out
some
way
to
actually
do
joint
work
with
the
unicode
consortium,
such
that
the
forcing
function
is
both
sets
of
parties.
Ietf,
folks
and
Unicode
consortium
folks
have
to
come
to
consensus
on
the
solution
set.
U
Leslie
Nagel
and
I'm,
largely
following
on
Pete's
comments.
I
think
in
it
I
think
the
problem
that
we've
had
with
working
with
relying
on
it.
The
Unicode
consortium
in
the
past
has
been
the
fact
that
they
have
different
priorities
and
different
purpose
and
don't
fundamentally
understand
the
things
that
are
terribly
important
to
us
like
once.
U
Although
I
agree
with
Pete
that
we
don't
currently
have
anything
like
the
expertise
to
do
this,
all
ourselves
and
I,
don't
think
we
will
ever
have
in
in
the
ietf
realm
the
expertise
to
replicate
all
the
work
that
the
Unicode
consortium
has
done.
Nor
should
we
so
I
think
we
need
something.
That's
maybe
not
a
working
group,
but
I
think
we
need
some
honest-to-goodness
IETF
based
activity
in
order
to
make
sure
we
get
the
attention
of
the
rest
of
the
IETF
work
to
you
know.
U
Listen
to
the
advice
that
comes
out
and
follow
these
guidelines
for
protocols
going
forward.
If
we
don't
have
something
that
is
grounded
in
the
IETF,
I
I,
don't
think
we're
actually
going
to
solve
the
problem.
So
that's
just
a
lot
of
words
characterizing.
What
I
see
is
the
problem
and
sadly,
no
real
answers
about.
U
S
Yeah
the
two
observations,
one
one
of
them
is
that
there
is
really
an
important
area
of
Nan
overlap
between
us
and
the
Unicode
consortium.
They
are
very,
very
good
at
coding
characters
and
we
would
be
totally
insane
to
go
into
that
business
that
we
would
know
it
we're
pretty
good
at
protocols
and
interchange
among
systems
and
certain
things
which
have
to
work
globally
rather
than
within
a
certain
known
language
context.
Although
we've
had
difficulty
extrapolating
that
general
knowledge
into
this
area,
making
it
work,
but
that's
an
important
distinction.
S
It's
it's
an
issue
off,
of
which
I
don't
know
how
to
move
forward,
but
when
we've
got
one
group
creating
a
standard
in
an
area
that
we
probably
we've
got
the
IETF
creating
a
standard,
an
area
where
we
presumably
know
quite
a
lot
like
the
DNS.
And
then
the
Unicode
consortium
comes
along
and
creates
a
standard
which
effectively
says
don't
use
that
standard
use.
Ours,
then
the
basis
for
collaborative
environment
is
a
little
fragile.
B
V
V
But
the
other
problem
is
that
people
developing
protocols
who
are
not
in
that
group
don't
understand
what
they
need
to
do
in
their
protocol
to
make
it
work.
We
see
very
often
just
falling
back
to
it
say,
utf-8
string
and
thinking,
that's
good
enough
without
worrying
about
all
of
the
issues
that
are
involved
with
comparing
and
normalizing
and
all
of
that
stuff
that
part
we
we
can.
We
can
do
something
about
that.
V
H
M
This
is
yo-yo,
Nia
I
think
this
problem
is
very
much
about
good
feedback
from
the
use
of
user
experiences,
not
only
the
bad
things,
but
also
the
good
things
and
to
solve
problems.
I
think
it
is
very
important
to
work
with
the
other
standardization
organizations
such
as
DC,
which
thinks
about
the
appearances
of
the
characters
or
usage
of
the
applications,
so
I
strongly
agree
to
and
walk
with
other
SD
hoods.
W
W
We
need
to
sort
of
get
over
the
idea
that
we
have
a
clear
idea
of
what
other
people
who
are
who
are
doing
are
trying
to
do
because
I
think
we're
miss,
describing
it
then,
and
that
that
misunderstanding
may
be
part
of
the
part
of
the
gap
that
we're
having
in
in
dealing
with
this
other
s.
Do
the
final
thing
that
I
would
say,
though,
is,
is
that
our
real
problem
here
has
to
do
with
the
thing
that
we're
normally
we
normally
regard
as
toxic,
and
that
is
this
is
really
a
user
interface
problem
right.
W
Q
Q
These
are
the
presentation
format
and
the
real
identifier
is
the
thing
you
get
when
you
apply
the
transform
to
get
the
IRI
back
into
a
URI,
and
so
your
eyes
are
our
thing.
We're
the
protocol,
people
we're
always
gonna
act
on
your
eyes
eye
our
eyes
are
totally
gonna,
be
a
presentation
layer
construct.
This
lasted
less
than
five
seconds,
as
XML
namespaces
immediately
used
our
eyes
rather
than
your
eyes
as
identifiers,
and
they
leaked
immediately
and
everybody
wanted
to
treat
them
as
if
they
were
their
own
construct
and
not
your
eyes.
So
it
was.
Q
Maybe
that
was
because
we
were
doing
it
and
we
were
mostly
protocol
people
but
I
think
it's
kind
of
unhelpful
for
us
to
say
this
is
a
user
interface
problem
and
and
since
we're
not
good
at
it,
we
we're
gonna,
try
and
create
an
interface
between
the
thing
we're
good
at
and
that
other
thing
and
let
somebody
else
take
care
of
other
thing,
because
our
experiences
things
just
leak
out.
The
other
point
I
I
kind
of
want
to
make
here
is
that
I've
had
some
very
good
discussions
with
the
Unicode
consortium.
Q
Q
You
often
have
to
know
not
just
what
script
is
in
use,
but
what
language
community
is
using
that
script
for
what
language
and
sometimes
what
era
it
is
if
you've
got
historical
documents
to
work
with,
and
we
look
at
our
own
systems,
which
are
primarily
around
known
item,
search
or
matching
for
things
like
passwords
or
user
names
or
DNS
labels,
and
that's
simply
not
context.
We
have
in
order
to
resolve
this
problem.
Their
view
of
what
we
should
do
is
change
our
systems
to
incorporate
that
context.
Q
Q
If
we're
really
gonna
tackle
this
I
think
we
can't
assume
that
we're
tackling
it
with
the
systems
we
have
nap.
We
have
to
really
be
willing
to
say
what
are
we
gonna
change
about,
how
very
fundamental
things
in
our
namespaces
and
applications
work
if
we're
really
gonna
pull
this
in
so
I?
Think
I
don't
wish
to
argue
with
John
at
all
that
this
is
important
work,
but
I
see
no
hope
at
all
that
a
special
review
team
could
say
this.
Q
T
Join
together,
harder
right
that
we
work
harder
at
getting
together
or
something
and
I
want
to
be
perfectly
frank
here.
The
problem
that
we've
seen
consistently
with
trying
to
interact
the
Unicode
consortium
is
we
do
it
so
far
in
a
very
formal
way,
using
things
that
look
like
liaison
statements
and
such
and
there
are
personalities
involved
and,
quite
often
from
either
side.
The
response
by
those
personalities
is
the
other
side
is
an
idiot.
T
And
sometimes
that's
true
in
both
directions.
What
I
think
I'm
suggesting
is
that
we
need
to
have
folks
from
the
Unicode
consortium
come
into
this
circle
and
vice
versa,
that
we
actually
do
figure
out
ways
within
each
set
of
procedures
to
insert
folks
into
those
procedures
and
actually
say
no.
The
answer
you're
doing
it
wrong
is
not
an
acceptable
outcome
in
either
organization
and
I.
T
B
U
U
I
think
that
what
I'm
hearing
in
part
is
that
we
should
actually
take
the
phrase
Unicode
consortium
off
the
table
and
sit
back
and
have
a
rethink
about
all
right
now
that
we've
gone
through
and
tried
these
different
approaches
to
things
which
worked
very,
very
small
lists
which
didn't
and
why
and
and
what
are
our
requirements
going
forward
and
that
sounds
exceedingly
painful.
I
will
observe
that
pain
is
conserved.
U
We
can
either
keep
having
this
conversation
over
and
over
again
and
making
no
progress,
or
we
can
step
back
and
do
the
architecture
thing
and
and
try
to
think
about
what
do
we
actually
need
to
re-engineer
and
and
change
in
our
approach
to
things
so
that
we
can
accommodate
accommodate
these
needful
things,
and
then
we
can
have
the
improve
our
dialogue
with
the
Unicode
consortium
or
whoever
else
and
I
take
that
back
to
John's.
Earlier
remark
that
we're
you
know
we're
pretty
good
at
designing
protocols
and
teasing
apart
requirements
and
whatnot.
B
X
X
S
I'm
very
sympathetic
to
that
point
of
view
from
other
parts
of
my
life,
but
there
are
backward
compatibility
problems
here
and
they
lie
at
least
as
much
on
that
side
is
on
the
other
side,
I
think
again,
taking
a
different
tack
on
Ted
statement.
I
think
I
think
we've
got
got
symmetrical
problems
here
in
terms
of
our
vocabulary
and
assumptions.
I
certainly
agree.
S
S
To
give
a
specific
example
from
from
a
variation
on
Joe's
remarks,
we
couldn't
code
all
that
stuff
with
identifiers,
but
then
the
question
would
be
how
to
use
it
and
how
users
would
encode
it
when
they
see
something
in
passing
and
we've
discussed
that
for
years
and
years
and
years
and
reached
no
conclusions
and
involved
unicode
people
and
they
haven't
been
helpful.
I've
involved
w3c
people
and
they
have
sometimes
been
helpful,
but
the
problem
spaces
are
a
little
different
and
that's
the
most
positive
view
of
this
mess
which
one
can
take.
He
says
the
problem.
X
Personnel
or
personality
issues
that
we
might
have
ascribed
to
certain
people
in
certain
places.
One
of
the
things
that
we
I
think
that
we
can
at
least
do
on
our
side
is
try
and
be
as
good
a
potential
partner
in
this
space
as
possible,
and
one
of
the
things
that
would
work
toward
that
is
us
being
able
to
at
least
listen
to
some
of
the
technical
input
that
we've
seen
from
a
variety
of
places.
S
W
X
T
A
It
sounds
like
we
have
we're
running
very
short
on
time
here,
but
I.
Don't
I,
don't
hear
a
close
to
this
discussion.
So
would
we
like
to
take
this
to
the
art
list
or
one
of
the
high
DNA
lists,
or
what
would
it
be
appropriate
next
step
here
for
the
interested
community
or
John?
Of
course
you
still
have
you're
still
on.
So
if
you
have
a
suggestion.
B
S
The
the
the
existing
mailing
lists
are
very
good
for
discussing,
or
not
so
good,
for
some
of
the
reasons
for
discussing
the
technical
protocol
issues.
But
the
immediate
issue
is
that
we've
got
these
drafts
floating
around.
We've
got
people
dependent
on
those
trusts
being
resolved
in
some
fashion
or
another,
and
we
have
another
way
to
process
them.
So.
D
A
V
There
there
there's
the
issue
of
getting
these
three
drafts
dealt
with
and
sure
we
can
talk
about
that
on
the
art
list
and
I.
Don't
think
there
are
any
other
lists
that
are
better
suited
for
that.
But
there's
the
broader
issue
of
what
to
do
about
the
problems
in
the
long-term
and
talking
about
it
on
that
on
the
art
list
is
not
going
to
help
us
particularly
I.
V
Don't
think
that
the
concern
that
I
have
about
forming
a
working
group
on
it
is
that
we
then
get
a
lot
of
people
who
really
don't
understand
the
issues
who
come
and
say
it's
simple.
You
just
have
to
do
this
and
we've
seen
that
happen
many
times
in
the
past,
so
I'm
I,
really,
yes,
it
was
in
one
in
you
just
said:
just
fell:
zurich
ze,
u
zu
e,
RI,
CH
and
you're
done
zi.
I
here
over
here
from
the
connait
from
canadian
anyway.
V
So
there's
a
lot
of
distractions
involved
in
that,
on
the
other
hand,
setting
up
a
review
team
of
the
people
who
understand
the
issues
and
can
go
pow
well
on.
This
makes
it
look
like
we're
closed
and
we're
not.
We
want
to
hide
something
I'm,
so
I'm
really
stuck
on
that
the
short
term.
We
just
need
to
get
these
three
drafts
sorted
out
on
the
art
list,
and
let's
do
that
for
the
longer
term,
I
don't
have
any
better
ideas
than
anybody
else
has
come
up
with.
B
A
It's
I
think
what
Mary
said
about
the
the
treatment
of
these
trees.
Documents
is
probably
quite
reasonable,
a
good
way
to
go
forward
on
the
larger
issue.
I,
what
I'm
going
to
repose
is
that
there's
been
a
lot
of
input
here
and
it's
not
all
necessarily
pointing
in
the
same
direction.
So
I
think
that
Ben,
Alexei
and
I
would
like
some
time
to
sort
of
put
our
heads
together
this
topic
and
then
come
back
to
the
art
list.
A
D
U
B
A
D
Martin
Thompson,
maybe
not
for
the
IAB
but
I'll,
point
out
that
we
hold
this
particular
issue
near
and
dear
to
our
hearts
and
are
actively
looking
at
ways
in
which
we
can
slice
off
a
piece
of
it.
That
could
constructively
be
turned
into
something
like
okay
work
item
or
a
workshop
or
a
program
or
something
like.