►
From YouTube: IETF99-DISPATCH-20170717-0930
Description
DISPATCH meeting session at IETF99
2017/07/17 0930
https://datatracker.ietf.org/meeting/99/proceedings/
B
D
E
C
C
D
C
E
E
D
E
D
E
Okay,
so
working
with
the
deadlines
mm-hmm,
if
you,
if
you
make
the
deadlines
and
obviously
you're
gonna,
get
agenda
time
as
long
as
the
topic
has
had
sufficient
discussion
and
sufficient
interest.
If
you
miss
the
deadlines
you
get
into
the
AO
B
section.
If
we
have
time
we'll
talk
about
it,
and
it
is
super
helpful
for
the
chairs,
if
you
include
your,
you
know
dry
off
your
name
dispatch,
it
makes
it
a
whole
lot
easier
for
us
to
just
make
sure
we
don't
miss
somebody,
because
we
do
occasionally
miss
somebody.
E
G
H
D
E
K
K
Next
slide,
so
the
the
proposal
came
out
of
some
research
about
emerging
markets
that
showed
that
users
have
this
existing
ecosystem
of
applications
that
they
use
to
share
files
around
and
we
wanted
to
let
them
share
websites
and
applications
in
addition
to
the
videos
that
they
that
they're
currently
sharing.
So
the
the
top
to
kind
of
use,
cases
drove
the
the
initial
design
of
the
format
and
then
a
bunch
of
people
came
out
of
the
woodwork
and
said
we
think
this
would
be
useful
to
us.
K
So
the
the
top
two
are
that
some
some
author
should
be
able
to
produce
a
bundle
of
their
their
website,
including
kind
of
service
workers
and
CSS
JavaScript
HTML
images
sign
it
and
then
let
people
download
it
and
share
it.
Peer-To-Peer
/,
cheaper
connections
like
Bluetooth
or
Wi-Fi
direct,
and
then
those
those
people
should
be
able
to
install
the
application
connect
back
to
the
original
server
and
and
treat
it
as
same
origins
so
get
get.
The
right,
URL
bar
get
the
right,
JavaScript
permissions,
and
so
on
second
use
cases.
K
Users
should
be
able
to
create
these
bundles,
which
means
we
also
need
an
unsigned.
A
way
to
do
them
unsigned
and
then
there's
some
use
cases
around
certain
certain
limited
CDN
ability,
so
its
intermediate
between
normal
CD
ends,
where
you
where
they
can
write
anything
as
the
as
the
website
and
and
just
copying
the
data.
K
Then
we
thought,
like
enterprises
might
might
want
to
give
extra
permissions
to
to
web
applications.
They
vouched
for,
and
the
format
also
seems
to
allow
that
some
people
want
think
that
HTTP
do
push
is
hard
to
to
configure.
So
they
think
that
web
packages
might
be
an
easier
way
to
do
that
and
then
some
node
node
people
and
web
publication
people
are
also
looking
at
using
the
format
next
slide.
K
So
in
order
to
get
the
peer-to-peer
website
sharing
things
have
to
be
signed.
We
have
to
make
sure
that
we
don't
get
around
sort
of
existing
certificate,
revocation
procedures.
We
have
to
make
sure
that
if
an
XSS
or
other
vulnerability
is
found
in
the
site,
we
have
some
way
to
to
prevent
that
package
from
from
being
used
by
by
attackers.
K
We
want
to
be
able
to
access
things
within
the
pack
randomly
rather
than
by
seeking
through
it,
so
that
people
using
SD
cards
can
can
use
the
packages,
and
we
need
to
be
able
to
update
the
the
algorithms
used
for
signing
the
packages
over
time.
So
we
need
some
way
to
to
tell
the
server
that
that
the
client
supports
certain
algorithms
and
then
ways
to
to
incrementally
upgrade
packages
to
support
both
old
and
new
clients
to
replace
em
HTML.
K
We
need
also
a
way
to
do
bundles
that
aren't
signed
next
slide
to
help
with
with
the
CDN
use
case.
The
package
needs
to
be
incremental.
This
is
one
of
the
two
considerations
that
that
makes
us
think
that
zip
isn't
the
right,
the
right
format,
so
we
want
to
be
able
to
kind
of
top-down
understand
a
package.
K
K
The
content
is
a
map
from
requests
to
responses,
which
is
the
second
reason
that
zip
doesn't
look
appropriate
instead
of
filenames
and
files.
We
have
like
HTTP
sessions
and
then
we
haven't
yet
designed
the
certificate,
validation
and
downgrade
protection.
But
we
we
expect
to
to
treat
that
as
kind
of
a
parallel
package
that
can
be
downloaded
more
frequently
and
passed
around
kind
of
attached
to
the
main,
the
main
content.
K
K
Let's
see
is,
is
a
packaging
format,
even
the
right
thing
to
do.
Maybe
we
should
just
do
new,
HTTP,
headers
and
and
then
some
parallel
bundling
format
that
that
would
definitely
not
be
here
and
then
we
need
to
nail
down
all
of
the
format
and
get
kind
of
any
other
feedback
that
that
people
can
see.
But
I
guess
the
main
question
question
for
this
group
is
like
what
venue
is
appropriate
is
it
here?
Is
it
a
new
working
group
is
an
existing
working
group
and
so
on
and
I
believe.
That's
everything
mark.
L
What's
really
annoying
about
there
we
go
hi
mark
Nottingham,
so
I
was
kind
of
one
of
the
folks
who
looked
at
this
said
no,
you
should
probably
do
it
all
the
w3c
at
first,
but
after
some
thinking
and
some
sleeping
well.
First
of
all,
I
should
say
that
there's
there's
a
bit
of
history
here
that
folks
might
not
be
aware
of
in
that.
The
w3c
has
thought
about
this
before
in
various
forms
and
the
w3c
T
had
a
document
that
has
been
going
on
for
quite
some
time
and
then
kind
of
died.
L
As
kind
of
you
know,
you
need
a
format
to
persist,
a
set
of
HTTP
requests
and
responses,
because
I
think
this
is
HTTP
specific
and
you
need
a
way
to
assert
that
a
HTTP
request/response
pair
is
from
an
authority.
So
that's
something
like
a
signature,
and
that
applies
to
you
know
either
a
package
or
to
an
individual
request,
and
then
you
need
so
the
glue
that
ties
that
into
the
use
cases
that
you're
interested
in
and
I.
L
L
I
L
L
Think
that
we
can
specify
a
format
to
persist,
HTTP
request/response
parents
in
a
convenient
to
consuming
way,
I
think
that
we
can
do
a
way
to
assert
that
a
request
response
pair
came
from
an
authority,
but
in
terms
of
and
so
those
are,
you
know,
kind
of
basic
functions
specifying
how
browsers
will
actually
go
and
support.
Those
in
certain
use
cases
is
is
maybe
out
of
scope
for
us.
We
just
want
to
define
the
basic
necklaces.
D
L
Just
pointed
out
to
me,
it
reminded
me
that
it
yet
to
persist
a
request
response
there
or
multiple
associated
request
response
pairs.
Obviously
to
get
that
gets
you
your
package,
II
stuff,
although
there's
some
pitfalls
there
and
if
I
put
my
ex
CDN
person
head
on
I
think
that
there
are
a
lot
of
pitfalls
around
those
use.
Cases.
I
think
that
this
is
HTTP
specific,
probably.
L
From
the
hip
thanks
our
work
mode
right
now
is
we
just
talked
about
a
document
decide
to
adopt
and
adopted
we'd
heart
recharter.
L
N
Tom
Baker
Komodo
I'm,
not
I'd,
look
for
it
a
few
times,
but
is
there
actually
a
proper
specification
for
mhtml
I
believe
not
yeah,
because
that's
something
that
I
think
you
need
to
fix
and
I.
Don't
think
that
it's
a
good
idea
to
do
this
in
HTTP
I
think
that
that's
a
working
group
that
has
no,
we
were
only
doing
two
sessions,
etc.
I
I
really
think
that
packaging
is
something
is
separate,
I'm
currently
working
on
something
related.
N
K
O
O
Q
Thomson,
unless
saying
what
about
this,
then
the
Marquis
I
think
when
I,
when
I
first
saw
this
I
thought
about.
Well,
this
isn't
yet
another
iteration
of
the
same
thing
that
we've
been
I've
had
pitched
to
me
umpteen
times,
but
when
I
actually
looked
at
your
requirements,
this
is
not
about
packaging
at
all,
and
it's
more
about
the
sorts
of
things
that
mark
was
talking
about
in
terms
of
passivating
HTTP
request/response
pairs
and
having
some
way
to
deal
with
them
offline
and
the
the
other
band
encoding
and
various
things
sort
of
pushes
in
that
direction.
Q
Generally
I'd
caution.
However,
we
don't
know
that
server
push
works
in
nature
too,
and
one
of
the
challenges
with
server
pushing
h2
is
having
someone
guess
what
someone
else
might
asked
for
and
when
and
there's
a
real
challenge
in
solving
that
particular
problem.
Yes,
the
come
on
my
market,
l
like
the
same
violets,
not
a
problem.
What
are
you
talking
about?
Q
We've
we've
had
that
that,
in
turn
of
the
beat
there's
been
a
lot
of
debate
about
push
and
and
how
to
actually
get
it
to
work,
and
it's
possible
that
within
a
narrow
context,
you
can
you
can
do
something
but
you're
you
are
creating
that
problem.
How
do
you?
How
do
you
determine
what
requests
that
someone
might
want
to
make
and
have
you
made
sure
that
they
have
the
things
they
need
to
actually
build
the
application
that
they
want
without
actually
talking
to
a
server?
Q
And
the
other
thing
is
with
we've
tilted
it:
the
signatures
windmill,
so
many
times
in
the
past
that
I
don't
know
that
we
have
this
well
I
personally,
like
the
stomach
for
it
anymore.
Is
it's
really
really
difficult,
and
it
may
be
that
one
if
we
can,
if
we
can
work
out
the
passivation
problem,
then
they
may
go
away,
but
yeah.
B
It
was
well
I
mean
the
passivation.
They
seemed
at
the
heart
of
the
problem
here.
You
know
it
was
already
kind
of
a
very
odd
hack
and
push
to
be
like
you're
about
to
ask
me
for
X.
You
know
here's
why
that
I
would
give
you
if
you
give
me
X
and
that's
like
things
are
milliseconds
apart,
how
you
get
be
weeks
apart
is
extremely
odd,
a
home.
B
What
do
you
mean
by
passivation
that
the
this
idea
of
here
is
that
the
request
which
you
might
be
about
to
send
me
and
the
basically
you
your
format,
contains
basically
requests
and
responses
as
if
these
were
like
beings
and
rewire,
but
they're,
just
sort
of
like
pre
can
write
yes,
and
that
is
like
an
odd
sort
of
structure
for
like
something
which
effectively
is
a
zip
file,
and
you
know
it
sort
of
made
sense
and
push
where
effective
we
were
trying
to
do
is
voices
in
the
HDPE
layer,
but
what
you
have
is
really
a
very
light
touch,
but
we
give
us
the
contrary.
B
I
actually
have
a
talk
about
the
security
for
a
second,
you
know
those
HTTP
credentials
are
there
for
a
reason,
and
it's
not
for
you
to
sign
things
over
the
long
term,
and
is
that
the
purpose
that
it
will
be
ID
to
be
concrete
about
this?
You
know
if
you
allow
HTTP
key
to
be
used
for
signatures
which
span
weeks
on
that
quits,
a
very
substantial
additional
risk.
If
that
server
was
ever
a
couple,
wised
yep.
R
Daniel
con
Gilmore
from
the
ACLU,
so
the
idea
that
this
is
framed
as
packaging
and
that
you're
talking
about
basically
shipping
web-based
applications
raises
all
kinds
of
questions
in
my
head
about
the
packaged
ecosystem
management
with
packaged
dependencies
and
things
like
that.
So
there's
a
long
history
of
work
with
this.
With
that,
you
know
Linux
distributions
with
language-specific
packagers
every
one
of
them
gets
it
wrong
and
it
is
really
complicated
to
get
the
dependency
management
and
to
avoid
things,
and
you
mentioned
downgrade
attacks.
It
says
something
like
not
yet
finished.
R
It's
also
not
designed
fully
an
NPM,
it's
also
not
designed
fully
and
PIP
it's
also
not
the
vengefully
and
Debian
I
mean
there's
there's
a
this
is
this
is
a
complicated
and
difficult
problem
in
an
ecosystem
that
is
centrally
managed
and
we're
talking
about
doing
this
in
ecosystem.
That's
distributed
I
just
this
is
a
if
you're
aiming
to
do
it
for
actual
packaging
like
full-on
packaging
work,
and
you
want
to
get
the
security
properties
right.
This
is
a
tremendously
large
endeavor,
so
I
just
caution
you
about
that.
Thanks.
R
Other
than
to
say
that,
like
we
should,
if
you're
gonna
do
this,
you
should
look
for
prior.
You
should
look
for
the
folks.
You
have
prior
art
in
it
and
and
make
sure
that
you're
not
making
the
same
mistakes
that
they've
made
we've
seen
for
greasing
language-specific
package
distribution
mechanisms
make
the
same
mistakes
that,
like
Linux
distro
package
distribution
mechanisms
made
ten
years
ago.
So
I
don't
want
to
make
another
ten
years
where
we
are
making
the
same
mistakes
down
the
path.
D
Alexei
we've
been
sort
of
discussing
off
the
mic
here.
How
we
feel
this
might
be
dispatched
and
mark
has
said
that
some
of
this
might
go
in
HTTP,
calling
feels
that
some
of
this
stuff
might
be
better
suited
for
a
small,
dedicated
working
group
sánchez.
Are
this
is
going
to
land
in
your
lap,
no
matter
which
way
that
goes.
So,
where
are
your
thoughts
on
this.
A
T
Think
we
need
to
have
a
more
fleshed
out
proposal
in
the
sense
of
which
piece
is
going
to
be
done
and
what's
deliverable
and
I
don't
want
HTTP
working
group
just
to
say
well
we're
just
taking
that
without
deciding
the
bigger
picture
or
what
this
is
going
to.
I
I
don't
want
to
give
the
answer
to
your
question.
I
think
it
might
be.
T
One
existing
working
group,
and
maybe
some
others
to
be
created
if
people
are
interested
but
I,
think
the
main
I
am
the
most
important
question
is
actually
are
people
interested
in
doing
this
work.
So
I
would
like
to
have
some
indication
that
you
know
it
looks
like
you
know.
People
came
to
the
mic
and
the
war
marginally
concerned
and
interested,
but
I
would
like
to
know
how
how
interested
people
I'm
so.
I
We
do
out,
but
let's
we've
got
a
lamp
behind
that
that
makes
sense,
good
input
that
this
looks
like
one
or
more
working
groups.
It
split
across
right
that
that
seems
to
be
where
we're
going,
and
we
need
you
more
details
on
that.
But
let's
do
people
there's
a
lineup
of
the
mic.
Let's
hear
what
people
want
to
say
and
let's
also
hear
anybody
wants
to
speak
about
the
relevance
of
this
and
whether
we
should
you
know,
are
there
people
interest
in
doing
this
work
and
then
will
will
a
specific
questions
like
Alexia
mark.
Q
Think
I
think
the
framing
is
packaging
is
immediately
maduk
and
the
core
things
that
you
actually
want.
If
we
can
solve
those
problems
and
I'm,
not
sure
that
we
can
completely
solve
all
those
problems,
but
we
may
be
able
to
make
some
serious
progress
on
them
if
we
can
solve
them,
it'll
be
good
to
actually
I'm
identify
those
individual
things
with
similarity.
R
This
is
d
kg
again.
Sorry,
I
just
wanted
to
clarify
my
earlier
comments
about
packaging,
which
is
that
well,
I
don't
see
that
there
is
a
place
within
the
ietf
to
do
that.
Work,
I,
think
if
you
go
ahead
and
you
define
signature
formats
without
actually
understanding
the
scope
of
like
what's
needed
to
be
signed
and
what's
not
needed
to
be
signed,
then
you
could
really
you
could
you
could
build
yourself
a
really
dangerous
thing
that
isn't
useful
for
the
for
the
actual
package
management
questions
that
you
want
to
answer,
I
didn't.
K
U
Ben
Schwartz
jigsaw
chair,
as
mentioned
speaking
to
relevance
I
just
wanted
to
say,
I,
think
this
work
is,
is
very
relevant
and
useful
to
my
my
needs
and
applications,
because
it
has
real
potential
to
serve
populations
who
are
who
are
cut
off
from
the
standard
internet
or
from
parts
of
the
standard.
Internet.
V
Paul
Hoffman
is,
is
actually
for
the
chairs,
on
whatever
hum
you're
gonna
ask
I
also
have
the
concerns
about
sign
packages
because
people
easily
misinterpret
them
in
the
DNS
world.
We
have
this
thing
of
you
know
you
watch
a
query
response,
then
you
sort
of
know
what's
there
and
it
sounds
like
one
of
the
things
you're
doing
is
sort
of
almost
mimicking,
but
so
ignore
the
fact
that
you're
packaging
it
but
you're
sort
of
saying
if
you
had
given
this
query
at
this
time.
V
V
Some
of
the
things
they
point
you
may
be
dead
and
such
like
that
I
am
really
concerned
about
signatures
over
some
things
that,
even
if,
even
if
the
signature
says
at
this
time,
you
would
have
seen
this
and
you
believe
that
I
think
it's
widely
open
to
misinterpretation.
Maybe
this
is
where,
where
dkj
was
going
so
I
would
say,
one
of
the
hums
might
be.
If
you
saw
one
of
these
things,
would
you
be
able
to
use
it?
I
believe
I
would
be
able
to
use
it
I
think.
V
Maybe
this
goes
to
what
Ben
was
just
saying
there
are
people
could
use
as
if
it
was
unsigned.
That
is
if
it,
this
is
just
a
chunk
of
things
you
might
have
gotten,
please
don't
believe
them
more
than
that,
but
the
the
signing,
I
think
is
going
to
be
really
easy
to
misinterpret,
especially
about
future
use
of
that.
B
Working
but
I
want
to
charter,
do
work
and
say:
like
here's,
the
Chinese,
kids
document,
here's
a
solution
which
we're
starting
from
doesn't
seem
like
a
very
good
place
to
be
so.
I
Yeah
they
were
getting
pretty
consistent
feedback
here
on,
like
hey,
there's,
work
to
be
done,
various
places
or
whatever
and
and
real
bad
and
so
on,
and
this
wasn't
trying
to
form
a
working
group
today
right,
we're
not
that
say,
they're
trying
to
divvy
up
the
work
and
get
the
requirements
like
like
multiple
people
said,
and
what
just
a
car
said.
I
I
Don't
know
Alexa,
you
got
any
other
questions,
you'd
like
input
on
and
okay.
Anyone
have
objections
for
us.
Have
it
running
this
discussion
on
the
art
mailing
list
for
a
while
and
if
the
traffic
gets
you
know
too
high,
which
I
don't
foresee
happening,
we'll
spin
up
a
separate
mailing
list
for
it,
but
doing
with
the
focus
initially
on,
like
let's
try
and
nail
down
better
context
of
what
you
know.
G
I
D
V
Close
enough
so
I'm
Paul
Hoffman,
some
of
you
remember
me
from
when
I
used
to
come
to
art
kinds
of
things.
Long
ago,
I
haven't
done
in
a
while
I'm
gonna
give
the
presentation.
Patrick
McManus
is
gonna.
Help
me
with
some
of
the
answers,
because
this
is
very
HTP
ish
and
he's
more
of
an
HTP
ish
kind
of
guy
than
I
am
I'm
a
DNS
kind
of
guy,
so
this
draft
has
been
out
for
a
little
bit.
We
have
a
no
one
next
slide,
please.
V
This
is
sort
of
a
tar,
baby
people.
It's
very
obvious
that
you
can
tunnel
foo
in
HTTP,
and
this
group
is
good
at
hearing
those
those
proposals
and
whacking
them
down.
We,
we
think
that
we
have
actually
dealt
with
some
of
the
obvious
questions
at
first,
but
the
main
reasons
that
we
want
to
be
doing
this
specific
kind
of
tunneling
with
and
for
this
specific
data
is
there's
a
couple
of
them.
It's
not
a
single!
Oh
you
know
this.
This
is
going
to
be
everything.
V
One
of
them
is
that,
in
fact,
htv-2
is
a
more
reliable
transport
for
this
DNS
queries,
and
we
know
that
browsers
and
other
you
know.
Http
itself
relies
on
domain
name
so
that
it
getting
the
DNS
data
itself
in
a
transport
that
it's
already
doing
is
a
logical
thing.
A
separate
orthogonal,
but
also
useful
use
case,
for
this
is
web
apps.
V
The
that
kind
of
information
could
be
valuable.
It
hasn't
been
available,
so
people
haven't
really
been
pushing
on
it,
but
remember
the
DNS
is
not
just
a
place
where
you
find
an
a
or
a
quad
a
record.
You
might
want
to
know
its
origin.
You
might
want
to
know
how
you
got
there.
You
might
want
an
SRV
record
things
like
that,
so
both
of
these
would
be
both
of
these
use.
Cases
are
achieved
by
doing
DNS
in
HTTP
and
to
be
clear
in
this
document.
V
We
are
not
saying
for
the
HTTP
client
what
you
can
do
with
this
DNS
information.
That's
completely
up
to
the
client
itself,
we're
not
saying
you're,
gonna
trust
it.
This
way,
you're
not
going
to
trust
it.
This
way
and
such
like
that,
it's
a
way
of
getting
to
dance
information
looks
like
so
also
to
be
clear
because
some
of
the
people
who
come
here
to
just
back
with
the
foo
over
HTTP
say
well,
we
only
want
these
parts
of
HTTP
and
so
we're
either
going
to
break
some
HTTP
semantics
or
just
ignore
them.
V
We
have
made
a
really
really
strong
effort
to
not
ignore
anything
from
HTTP
and
to
do
it
right
so
constant
negotiation,
proxy
and
caching
blah
blah.
All
of
that
either
we've
already
done
or
we
intend
to
do
or
if
we
did
it
wrong,
we
intend
to
fix
it.
We
aren't
trying
to
do
HTTP
except
X,
Y
&,
Z
yeah.
We
want
this
to
be
really
speed
because,
again
from
that
first
slide,
we
want
this
to
be
used
by
HTTP
clients
already
and
we
don't
want
HTTP
client.
That
is.
Are
you
shaking
your
head?
V
No,
are
you
playing?
Thank
you,
okay,
good
who
is
like
ooh
boy,
okay,
because
this
is
really
basic
to
our
idea
is
if
you're
an
HTTP
client-
and
you
want
this
DNS
information.
You
shouldn't
have
to
forget
part
of
your
brain.
When
you
get
it,
it
should
be
just
like
stuff
that
you're
getting
so
we
really
do
want
to
you
know
just
do
all
the
best
practices,
stuff,
etc.
So
next
slide
we
have
a
bunch
of
things
where
people
said.
Oh,
you
could
also
do
this.
We're
not
doing
that.
So
we're
not
you
know
dns64.
V
It
was
a
bad
idea.
We're
not
gonna,
try
to
touch
it
and
the
last
two
bullets
are
the
most
important
ones.
We
are
not
trying
to
support
insecure
HTTP.
This
is
h2
over
TLS,
just
like
the
way
h2
is
supposed
to
be,
and
therefore
its
h2,
which
is
not
h1.
H1
point
one,
eight
zero
point,
one.
Whatever
the
you
know,
we
are
not
trying
to
say:
oh
well,
if
you
don't
really
know
all
of
HTTP
or
turn
HTTP,
you
can
still
use
this.
No,
this
is
for
mainline
HTTP
next.
V
So
let
me
do
a
few
slides
for
those
of
you
haven't
looked
at
the
current
draft
of
how
it
looks
today,
I'm
emphasizing
today,
because
in
fact
it's
just
an
o1
draft.
If
dispatch
dispatches
this
somewhere
and
such
like
that,
then
you
know,
this
is
all
open
just
in
the
same
way
that
lots
of
HTTP
groups,
one
of
the
most
important
things,
is
that
you
marshal
the
DNS
wire
format
for
your
query
and
for
your
response,
which
takes
a
little
bit
more
work.
V
But
what
you,
what
you
get
out
of
that
is
full
support
for
DNS.
So,
instead
of
this
being
sort
of
like
well
right
now,
you
can
get
addresses
and
we
want
to
give
you
some
more
and
will
tell
you
which
more,
the
the
mandatory
to
implement
content
format
is
the
full
DNS
request,
the
full
DNS
response.
Now
there
might
be
additions
later
for
different
formats
that
are
less
than
that
and
easier
and
I
have
a
slide
on
that.
V
But
the
idea
here
is
that
the
the
DNS
folks
on
one
of
those
there's
a
few
other
in
the
room
have
already
said.
This
is
the
way
the
DNS
world
looks.
This
is
the
kind
of
data
you
can
get.
That
kind
of
data
should
be
available
to
a
DNS,
client,
I'm,
sorry
to
an
HTTP
client,
so
we
use
the
wire
format
and
in
the
current
draft
we
also
do
get
and
post
some
people
have
said
we
need
to
pick
one
I've
got
examples
of
both
of
them.
Each
of
them
has
their
own
use
kit.
V
You
know
their
own
value
case.
They
both
have
are,
you
know
like
90%
the
same,
but
the
last
10%
is
different
for
the
two
of
them.
But
right
now
the
draft
says
here's
how
to
do
a
get.
Here's,
how
to
do
a
post
next
slide
and
here's
what
the
gate
looks
like,
which
is
a
normal
get.
The
one
funky
thing
in
here
that
you
might
notice
is
in
the
path
we
actually
put
the
content
type
as
part
of
the
path
piece
so
that
you
can
see
that
and
again
we
are
content
type
agnostic.
V
So
this
is
the
content
type
that's
described
in
the
draft,
which
is,
as
you
can
tell,
from
the
name
since
content
types
are
supposed
to
have
descriptive
names,
this
the
DNS
UDP
wire
format.
So
that's
what
it
is,
and
then
the
body
is
that
you
know
done
out
as
basics
t4
and
such
like
that
notice
on
the
last
line,
though,
that
in
fact
it
can
accept
answers
both
in
the
wire
format
or
in
this
other
one
that
I
made
up
with
simple
DNS
or
others.
V
So
again,
like
normal
HTTP,
the
query,
the
query
format
doesn't
have
to
match
the
answer
format,
if
you're
able
to
do
that
next
slide
and
so
post
looks
similar,
except
for
the
fact
that,
of
course,
you
have
content
type
as
a
real
header
and
such
like
that,
but
looks
like
a
normal
post
next
slide
and
then
the
response
you
get
back.
This
is
an
example,
the
response
coming
back
in
the
wire
format.
V
It
looks
like
what
you
would
expect.
Hcv
response
to
look
like
and
again
that
glob
of
hex
at
the
bottom
is
a
real
DNS
response.
If
you
have
a
DNS
parser
for
the
message
that
will
come
out
looking
exactly
like
what
you
would
expect
next,
so
as
I
said
earlier,
we
are
saying
mandatory
to
implement.
Implement
is
the
wire
format,
because
that
gives
you
all
of
DNS.
There's
nothing
more
to
give
you.
V
If
you
can
do
the
wire
format,
there
might
be
other
content
types
that
people
want
and,
for
example,
for
web
apps
for
Jason
a
Jason
app
might
just
want
an
address,
but
it
wants
to
be
get
the
A's
and
the
quad-a
records.
You
know
at
the
same
time,
so
I
did
a
draft,
a
really
simple
draft,
which
is
called
simple,
DNS
JSON,
which
you
know
the
query
looks
like
Jason.
The
response
looks
like
Jason
blah
blah
blah.
Other
people
could
do
others.
V
This
one
might
be
expanded
more
to
say,
cover
it
SRV
and
such
but
I'm,
not
saying
that
this
is
a
right
answer
or
a
good
answer.
We're
just
emphasizing
the
fact
that
this
is
really
an
HTTP
usage,
so
content
types
can
be
added
next
right
and
then
so
really.
The
question
is
so
why?
Why
are
we
coming
here?
V
We
want
enough
other
review,
because
this
is
DNS
folks,
HTTP,
folks
and
sort
of
app
see
folks.
So
we
would
like
a
working
group
that
might
do
that.
We
think
this
is
pretty
easy
to
charter
and
I
sent
you
as
one.
You
might
sew
items.
I
didn't
put
it
up
here,
but
it's
just
a
few
sentences
that
Cullen
said
he
would
love
something
that
was
three
sentences.
Long
I
think
I
made
four,
but
it
yeah
your
honor.
V
V
S
O
S
You
move
this
to
an
HTTP
client
which
could
be
a
which
could
be
a
browser.
So
one
of
the
potential
use
cases
here
right
is
simply
you
know
in
place
of
a
stub,
resolver
and
an
HTTP
client,
and
then
you
find
a
name
server
in
the
same
way
as
you
currently
do.
Bootstrap
through
some
kind
of
you
know,
operating
system
mechanism.
Maybe
a
PVD
will
give
you
a
name
along
with
an
address,
so
you
can
use
that
for
the
HTTP.
You
know
establishment
of
that
connection,
and
that
also
applies.
S
You
know
in
the
browser
context
right
in
order
to
find
the
recursive
resolver
it
wants
to
talk
to
or
how
the
application
wants
to
find
the
recursive
resolver.
That's
going
to
give
it
these
things
might
be
application
specific
configured
run
by
the
JavaScript
application
that's
distributed.
Our
intention
is
that's
actually
out
of
scope
for
this
working
group
discovery
problems.
This
says
you
know
you
have
the
name
of
a
name
server.
Just
the
same
thing.
S
S
Gets
cached
yeah,
so
you're
talking
about
like
the
use
of
this
information,
so
I
mean
the
clients
already
have
this
problem
right
now
they
have
a
number
of
options
of
DNS
sources
available
right
I
mean
I
can
use
the
one
identified
by
mile
and
I
keys
one
at
each
minute
by
my
ISP
I've
got
the
one
identified
in
a
quad
8
right.
You.
V
S
To
allow
you
to
use
new
ones,
so
so
these
to
be
working
group
right
now
is
taking
on
some
questions
about
how
you
do
or
do
not
use
DNS
information
in
particular
scenarios.
That
is
not
this
work,
so
so
things
like
alternate
services,
which
we've
already
there's
already
an
RFC
on
right,
defines
a
HED,
client,
specific
relationship
to
routing
essentially
right
to
use
any
data
through
this
mechanism
that
say
came
directly
from
the
origin
that
you
happen
to
be
talking
to
would
require
further
work
in
a
place
like
HTTP,
for
how
you
use
this
information.
S
What
this
work
is
about
is
defining
how
you
carry
traditional
DNS
information
over
HTTP
and
like
what
the
meaning
of
those
fields
are.
When
you
do
that,
so
you
can
map
that
back
into
the
old
meaning
and
that's
the
extent
of
it,
and
it
intends
to
be
a
fool
over
HTTP
draft
done
in
a
way
that
is
well
aligned
with
the
needs
and
goals
of
HTTP,
which
is
not
always
the
case,
so
we
actually
kind
of
want
to
use
it
as
a
little
bit
of
a
trial
balloon
for
establishing
it.
It's
a
good
example.
So.
V
L
Mark
Nottingham
I
think
this
is
good,
I
think
it's
just
the
right
scope,
I
think
you're
right.
It
should
be
easy
to
charter
finishing
tests.
I
think
it's
the
right
decision
to
punt
on
on
how
it
gets
used
for
now.
There
are
a
couple
of
all
these
cases
in
there
couple
non-obvious
cases,
but
that's
a
separable
discussion
and
this
is
achievable.
If
you
keep
it
tightly,
scoped
I'll
probably
have
some
I've
already.
Given
you
some
feedback
and
I'll
have
some
more
and
I
die
from
my
discussions.
L
L
An
explicit
goal
of
this
work:
it
should
be
on
a
charter,
so
that
would
be
cool
yeah
and
and
I
have
some
suggestions
which
week
I'm
happy
to
talk
through
one
thing
you
said,
and
there
was
some
discussion
on
jabber
about
why
h2?
Why
not,
as
you
said,
legacy
HTTP
I
think
it's
entirely
reasonable
to
specify
a
minimum
version.
If
you
have
some
particular,
you
know
mandatory
to
implement,
for
example,
in
terms
of
performance
and
security
goals,
but
you
need
to
care
for
other
language
and
especially
don't
call
HTTP
one
legacy
HTTP,
please!
S
Right
so
I
mean
there
are
some
justifications
for
that
and
the
requirement
is,
as
you
say,
a
minimum
version.
It's
not
h2
its
HT
two
or
greater,
and
we
rely
on
the
the
semantics
to
find
at
that
layer,
which
is
the
goal
I
mean
in
the
mechanisms.
The
draft
goes
into
the.
Why
that
was
mechanism
I
think
are
appropriate
here.
It's
the
priority
of
multiplexing,
and
you
know
one
things
I
like
about
7540.
Is:
it
sets
an
existing
best
practices,
security
bar
that
h1
cannot
be
expected
to
because
of
its
older.
L
Older
status
well,
one
of
the
interesting
things
you're
gonna
have
to
work
through
in
this.
If
this
goes
for
it
is
what
happens
when
the
peers
virtually
agree
to
downgrade
HTTP.
If
you
want,
is
that
allowable
in
the
protocol,
or
do
you
sacrifice
interoperability
there,
because
there's
some
cases
where
that
might
happen,
for
whatever
reason
easy
to
add.
J
Dave
Lawrence,
so
I
agree
with
mark
that
this
is
very
good
and
useful
work
that
we
should
pursue
further
and
I
like
what
you've
done
so
far.
I
disagree
with
mark,
to
the
extent
that
we
should
just
pump
on
use
cases,
the
issue
being
as
I
see
it
and
as
I've
complained.
All
in
the
past
is
that
DNS
over
HTTP
is
a
very
ambiguous
term.
J
M
J
W
Saturday
as
so,
if,
if
what
you're
doing
is
as
you've
described
to
Magnus
you,
you
find
your
DNS
server
by
some
existing
method
that
you
would
find
any
other
DNS
server.
You
make
a
connection
to
it
and
you
treat
it
as
you
would:
a
recursive
or
an
authoritative
server,
recursive,
specifically
okay.
So
let's
say
in
this
case
it's
a
recursive
server.
You
found
it
you're,
treating
it
that
way.
It's
a
little
bit
unclear
to
me.
Why,
then
this
isn't
something
we
could
just
fold
in
to
deprive
all
of
the
complications
that
I
see
in
this.
W
Services
that
it
becomes
something
that
isn't
this
is
a
a
deprived
mech
mechanism
that
happens
to
use
HTTP
rather
than
DNS
over
TLS
or
DNS
over
D,
TLS
and
I
think
it
would
be
very
valuable,
as
you're
going
through
the
dispatch
process
to
think
about
what
pieces
of
this
wouldn't
work
in
deprived,
and
why?
Because
that
might
help
you
charter
this
in
a
way
that
keeps
you
out
of
some
of
the
the
muddy
waters
that
would
be
problematic
to.
V
W
I
agree:
it
would
take
a
returner
for
deep
prep,
but
I
think
a
different
way
to
look
at
the
deprived,
Charter
is
to
say
it
is
about
new
substrates
for
the
DNS
protocol,
which
provide
privacy
and
I
believe.
One
of
the
things
you
are
creating
is
a
new
substrate
for
the
DNS
protocol,
which
provides
privacy.
That
may
not
be
the
the
the
raison
d'etre
for
for
des
privacy
may
not
be
the
raison
d'être
for
your
work,
but
it
is
a
required
result
of
your
work,
and
that
is
a
good
reason,
I
think
to
think
about.
X
Keith
moon
I
think
this
seems
like
a
huge
can
of
worms
to
me,
and
one
of
the
things
I
find
myself
very
concerned
about
is
the
possibility
that
this
ends
up
essentially
forking
DNS
and
ending,
with
a
more
or
less
a
special
set
of
DNS
servers
that
are
intended
for
use
by
web
applications,
because
you
know
you're
providing
what
is
more
or
less
a
web
specific
interface
to
DNS.
Now
it
doesn't
mean
I,
don't
know
that
it
has
to
be.
Is
that
way
you
could
presumably
write
on
any
application
that
used.
X
You
know
DNS
over
HTTP,
but
most
likely
it's
going
to
be
used
by
you
know.
Web
applications
and
I
feel
like
DNS
is
already
polluted
enough
as
it
is.
There
are
way
too
many
interception
proxies
and
special.
You
know
servers
that
only
serve
parts
of
domains
and
things
like
that,
so
that
the
fundamental
original
goal
of
DNS,
which
is
that
it
provides
the
same
view
of
the
Internet
everywhere,
has
long
been
compromised.
But
we,
you
know,
that's
water
under
the
bridge.
X
S
S
But
when
you
do
this,
you
get
better
mixing
with
existing
HTTP
and
HTTPS
traffic,
which
has
strong
properties,
for
you
know,
making
traffic
analysis
a
little
bit
harder,
and
that
kind
of
thing
right
so
I
certainly
think
there
are,
and
certainly
much
better
privacy
properties
than
traditional
DNS
right.
So
I
certainly
hope.
There's
a
role
here
for
things
other
than
you
know.
Web
applications
and.
V
This
is
not
intended
to
do
the
split
that
you're
worried
about.
In
fact,
it
seems
likely
that
if
this
protocol
exists-
and
there
are
servers
out
there-
let's
just
call
them
servers
that
want
to
do
this.
A
current
DNS
server
could
easily
add
the
HTTP
server
part
to
do
it,
so
it
could
be
the
same
server
with
exactly
the
same
data.
There's
nothing
that
says.
Oh,
this
is
somebody
who's
only
talking
to
Web
Foods.
It
would
be
very
easy
to
add,
if
you
think
of
it,
as
another
transport
I
mean.
Y
Hi,
this
is
from
John
Clinton
in
tavern
I'm,
trying
to
figure
out
what
it
would
mean
to
use
content
negotiation
to
select
variants
as
one
of
the
slides
indicated,
given
that
DNS
does
not
support
a
give
me
all
the
aliases,
for
this
name
function
much
less
their
properties.
The
draft
talks
about
alternatives,
but
doesn't
seem
to
say.
Could
you
give
some
more
info
about
that.
V
Right,
yeah,
the
content,
negotiation,
John,
maybe
misunderstand
the
content,
negotiation
I
thought
we
were
clear
in
the
draft.
I
might
have
misstated
it
up
here,
but
that's
not
for
different
names
or
different
views
of
names.
It's
for
the
format.
That's
coming
back,
whether
it's
coming
back
in
wire
format,
jason
asn.1,
whatever
so
yeah
it.
Wouldn't
you
wouldn't
use.
You
wouldn't
use
that
negotiation
to
say.
I
want
these
different
kinds
of
names
so
and
if
that's
not
clear
in
the
draft,
it
really
really
should
be.
Z
V
V
No
because
deprive
you
can
actually
tell
that
it's
a
deprived
session.
So
if
you
want
to
block
DNS
traffic,
you
can
say
oh
I'm,
gonna
block
traffic.
That
looks
like
deprive
where
is
this
might
be
something
where
it's
already
up,
especially
because
we're
using
h2,
then
you
can,
and-
and
this
is
a
real
use
case-
is
let's
say
that
you
have
you're
using
regular
DNS
to
get
an
h2
session
up.
Then
you
can
switch
into
this.
V
AA
AA
V
Z
You
don't
so
anyway.
The
same
firewall
trials
tends
to
also
negotiate
clients
servers
down
from
HTTP
to
to
http
one
by
just
throwing
the
LPN
extension
out
so
I
think
maybe
you'd
like
to
say
HTTP
rather
than
HTTP
two,
because
of
because
those
really
get
negotiated
down
with
browsers
that
they're
willing
to
negotiate
down
for
HTTP
one.
So
if
an
implementation
of
this
draft
is
not
willing
to
negotiate
down
to
http
one,
it
might
get
blocked
right,
so
I
think
I
can.
Z
S
So
in
HPV,
space
post
has
a
better
content
negotiation
dynamic
because
the
content
type
and
the
415
media
type
not
requested
response
header
pretty
much
applied.
A
message
body
is
not
URLs
right,
so
it
enables
it
enables
media
negotiation
in
a
little
bit
better
way.
The
two
methods
are
complementary:
they
both
move
the
same.
You
know
semantics
of
DNS
data
back
and
forth.
One
has
better
content,
negotiation
properties,
the
other
has
essentially
but
our
caching
properties
menu.
As
we
put
on
the
slides.
S
Y
R
R
I
am
concerned
about
the
content,
type
negotiation.
That
seems
like
extra
hairball,
that
maybe
we
don't
need
to
wrap
in
you
mentioned
that
they
have
the
same
semantics
for
some
different
structures.
I,
actually,
don't
think
they
have
the
same
semantics
in
particular,
because
DNS
SEC,
you
can't
validate
DNS
SEC
over
the
JSON
format
unless
I'm
misunderstanding
it
DNS
SEC
signatures
are
signed
over
the
DNS
wire
format
or
some
particularly
parse
barrington,
that
if.
R
So
I'm
just
suggesting
that
it
would
be
I
think
pruning
off
the
excess
that
the
non-mandatory
to
implement
wire
formats
would
be
a
useful
simplification
to
make
sure
that
we
can
get
this
out
the
door,
because
I
think
that
people
are
going
to
want
to
be
able
to
deal
with
DNS
SEC
and
many
of
the
consumers
of
this
and
the
extra
wire
format.
The
extra
the
non
UDP
wire
format,
the
JSON
wire
format,
as
far
as
I
understand,
doesn't
have
a
clear
way
to
represent
DNS
X
signal.
R
Unless
your
client
already
has
a
wire
format,
parser
or
something
close
to
it.
So
I
would
recommend
pruning
that
off.
I'm
happy
to
not
have
discovery,
be
part
of
this
I.
Don't
think!
That's
something
that
we
need
I
just
like
to
say.
Here's
the
way
to
do
the
transport
that
is
compliant
where
there
should
be
semantics,
I'm,
not
so
sure
about
the
idea
that
there's
just
arbitrary
end
points.
We
have
dot
well-known
for
a
reason
and
I,
don't
know
I,
don't
understand
why
this
draft
doesn't
just
pick
a
end
point
within
dot,
well-known
and
say.
A
R
It
does
so
it
does,
but
then
it
also
says
oh
and
then
you
could
also
do
it
in
all
these
other
places,
based
on
our
betrayer
endpoint
provisioning,
I'm
saying
maybe
we
could
prune
that
as
well.
If
you
want
to
simplify
it
and
I,
do
appreciate
the
the
requirement
for
h2
so
I'm.
Sorry,
there's
a
bunch
of
comments.
No.
V
B
That
are
good
this
first,
a
little
sad
that
were
looking
at
this,
like
essentially
writers,
were
sterilizing
d-prime,
since
it
seems
like
when
we're
not
one
believes
that
whether
one
believes
that
the
this
particular
D
pipe
is
obviously
a
superset
and
so
like
it
seems
like
very
annoying.
There's
no
reason.
That's
where
we
are
I'm
gonna
put
a
little
bit
on
this
observation
that
haven't
made
I
think
that
you
can
somehow
have
your
HTTP
connection
up
and
that
you're
miss
your
DNS
requests.
I,
don't
know,
I
should
see
how
that
works.
B
So
I'm
as
obviously
the
case
that,
if
you're
connecting
to
Google
your
DNS
servers
guru,
then
maybe
it's
doable,
but
the
server's
not
Google,
and
so
you're,
not
sending
Gantz
requests
to
anything
HTTP
and
DNS
or
the
say
channel
to
anybody.
So
I
should
understand
how
you
get
in
the
situation.
So
can
you
scroll
over.
S
B
V
So
you
might
have
a
list
of
P
of
a
large
number
of
servers
that
you
would
be
happy
with
right
now,
since
your
you're
carrying
a
laptop.
If
you
go
to
a
coffee
shop,
you
sort
of
are
inherently
saying
and
when
I'm
in
a
coffee
shop
I'm
happy
to
have
whatever
they're
recursive.
It
is
most
people
probably.
B
A
personal
argument:
wall
I'm,
sorry,
putting
all
the
professor
argument:
the
coffee
shop
controls
my
IP
connection.
Yes,
that
is
not
the
situation.
We
say
the
Akamai
servers
that
are
running
Facebook,
no.
V
B
V
S
It's
the
HDP
VPN,
there's
also
others
how
many
mechanisms
in
play
here
I
mean
like
clearly
their
end
varieties
of
tunnel,
we're
trying
to
do
specify
something
more
than
a
tunnel
here,
we're
trying
to
specify
a
useful
definition
of
foo
over
HTTP
that
aligns
with
itself
in
a
way
that's
more
than
a
tunnel.
That's
that's
part
of
the
question.
I
understand.
B
That
point,
but
I
guess
yeah.
B
Iii
I'm
funny
my
selfish
way.
This
is
actually
realistic
use
case
of
hiding
this
traffic
and
the
point
we
were
basically
HTTP,
VPN,
there's
a
whole
pile
of
other
things
that
they
do
to
make
the
system
work
and
and
there's
certainly,
we
include
tooling
HT,
generate
any
ideas
or
HTTP
so
so
well,.
B
Like
the
the
case,
if
I'm
much
more
aggressive,
perhaps
people
in
favor
of
pepper-
that's
it
is
that,
as
opposed
to
deprive
this
conceals
the
LVN
token,
this
is
lying
about
the
fact
that
you're
doing
DNS
this.
V
B
Like
an
extremely
fine
semantic
playful,
especially
the
enforcement
agent,
I
mean
they're,
like
the
purpose
of
this,
for
the
enforcement
agents
perspective
is
to
control
what
you
do
and
so
like
and-
and
you
build
this
as
a
as
a
policy
vision
mechanism,
so
I
can
try,
says
you
backing
off
that
now.
I'm.
V
M
B
Yeah
so
in
case
on
the
the
second
part
I
got
to
make,
is
I
really
like
to
see
a
pretty
clear
division
between
this
case,
which
is
effectively
deprived
plus
plus
in
this
case,
which
is
applications
should
be
doing
DNS
from
from
from
like
xhr,
you
are
see
a
separation
in.
B
B
B
Right
so
yeah
so
for
sure
again
we're
talking
pathetical.
D
G
And
what
I
actually
have
three
points?
I'm
gonna
go
through
them
very
good.
The
first
was
about
we're.
Browsers,
are
going
to
want
to
use
this
a
fine
example
of
something
that
can't
do
DNS
at
the
moment.
It's
thunderbird.
It
can't
do
s
Avila
cups,
because
it
doesn't
have
a
cross-platform
way
to
do
SRB
lookups
and
that's
that
kind
of
application
where
they
want
to
do
a
lookup.
That's
not
just
an
a
record
and
they
want
to
be
cross-platform.
This
seems
fantastic
for
the
second
thing
was
HTTP
2
vs.
HQ
1.1.
G
And
the
third
point
there
was
the
format's
and
requiring
only
the
UW
wire
format.
It's
going
to
be
a
lot
more
complex
for
the
developers
to
deal
with
that,
rather
than
a
simple
JSON
format,
where
you
say:
here's
the
key.
Here's
the
value
I
want
to
look
this
up.
Not
everybody
wants
to
do
DNS
lookups.
Some
people
just
want
to
look
up
a
record
and
get
a
response
back
there
in
an
environment.
G
U
P
Godmy
just
a
question:
is
it
considered
one
of
your
use
cases
that
a
JavaScript
application
could
implement
this
with
the
browser
being
completely
ignorant
of
it,
so
that
you
know
it
could
just
make
the
cookie?
You
know
if
it
in
wanted
SRV,
lookups
or
DNS,
SEC,
validation
or
whatever,
though
I'm
sure
that'd,
be
annoying
to
do
in
JavaScript
yep,
so
so
that
so
the
idea
is
this
could
be
an
entirely.
The
browser
can
be
completely
ignorant
of
this
and
will
also
work
right.
D
I
Okay,
so
we're
struggling
here
between
how
much
this
relates
to
deep
breath
and
how
much
this
relates
to
a
you
know,
new
working
group
that
was
spun
up
about
it.
How
much
this
relates
to
doing
nothing
at
all.
You
know
hear
comments
on
sort
of
you
know
the
range
of
how
we
split
this
work
up,
what
parts
of
it
does
how
it
relates
to
existing
things
we
have
at
ITF,
particularly
from
an
ad
RT.
T
T
I
Y
D
D
Nice
to
see
you
again,
if
there
anybody
who
wants
to
chat
about
give
a
quick
summary
of
these,
we
don't
need
them
necessarily.
We
can
keep
moving
right
along
going
once
going
twice
and
the
only
other
working
group
that
has
formed
since
ITF
98
is
Dee
Krupp,
which
is
I'm
since
I
co-chair.
That
I
can
give
the
overview
of
it,
mostly
just
upgrading
key
size
recommendations
and
possibly
developing
some
ways
to
move
larger
keys
through
D
Kim
and
through
the
DNS.
Since
those
are
limited
in
the
current
specification
shouldn't
its
meaning.
D
AB
Just
to
route
this
is
barely,
but
just
to
repeat
what
I've
sent
to
the
mailing
lists.
We've
shifted
the
meeting
time
D
crop
session
with
right
with
D
mark
and
was
supposed
to
start
at
11:30
know
at
11
o'clock
and
we've
moved
it
back,
20
minutes
to
start
at
40
so
that
it
you
don't
have
to
sit
around
in
the
room
for
a
half
an
hour,
doing
nothing
waiting
for
it.
Thank
you.
Dave.
AC
All
right
so
I'm
going
to
be
talking
about
your
eyes
with
multiple
transport
stacks
next
slide.
Okay,
so
recently
you
can
buy
recently
I
mean
since
last
IETF.
There
have
been
at
least
three
relevant
requests
for
your
I
schemes
that
all
have
a
common
property.
Okay,
they
were
all
asking
for
I.
Have
this
protocol
and
I
want
to
have
you
know
food
TCP
in
food
out,
UDP
and
food
out?
You
know,
fill
in
the
blank.
That's
the
category
of
stuff.
AC
Those
three
requests
that
I'm
aware
of
the
first
one
was
from
the
core
working
group
which
requested
co-op
or
where
various
transports
right
originally
co-op
was
just
over
UDP
and
now
they're,
adding
transports
for
TCP
and
WebSockets
and
so
on.
So
that
was
the
first
trick
question,
so
they
asked
for
a
co-op
plus
TCP.
As
for
those
four
schemes,
in
addition
to
the
other
two
that
are
whether
you
point
now.
AC
Second
category
was
frog.
Actually,
the
second
and
third
were
from
other
stos,
the
suckit
one
said
yeah.
We
just
want
to
use
what
core
did
right.
We
have
a
dependency
on
those
because
we're
doing
some
products-
and
so
ocf
said
hey,
you
know,
can
you
please
just
register
those?
We
support
that
and
if
you
don't,
then
we'll
just
provisionally
register
them
ourselves.
Okay
and
since
the
IETF
basically
said
at
the
time.
Well
we're
still
trying
to
figure
that
out.
We
don't
know
what
they
have
consensus
and
so
on.
AC
So
right
now
those
are
actually
provisionally
registered
to
ocf
and
ocf
was
like
well
you're
welcome
to
have
them
back
if
you
want
them
right
pending
this,
but
in
the
meantime,
ocf
is
going
to
use
them
anyway.
So
that's
kind
of
one
of
the
things
that
happened
and
then
the
third
one
was
a
different
SEO,
which
is
the
OPC
foundation
right.
So
both
ocf
and
OPC
foundations
are
two
different
IOT
SDOs
right,
one
is
stronger
in
the
consumer
space
one
is
stronger
than
the
industrial
space.
AC
They
also
asked
for
a
permanent
registration
of
Oh
PC
over
TCP
and
a
and
Q
PE
and
WebSockets
okay,
I
just
so
happens
that
both
of
them
were
ones
that
we're
using
stuff
and
I
poke
them
to
say:
hey,
you
guys
should
register
your
stuff,
and
so
technically
you
can
blame
me
for
this
becoming
public,
because
I
noticed
this
and
poked
them,
okay,
and
so,
as
a
result
of
that
on
the
uri
review
list
and
various
other
lists.
There
was
lots
of
discussion
about
whether
this
was
a
good
idea
or
not.
AC
Okay
and
so
I
wrote
a
draft
to
collect
a
bunch
of
the
arguments
and
trade
offs
and
issues
right
now.
This
is
not
a
document
that
tries
to
make
any
recommendations.
It's
a
document
that
surveys,
here's
the
possible
things
you
can
do
and
here's
the
limitations
and
advantages
and
disadvantages
of
the
various
approaches
for
people
to
finding
URI
schemes
daddy.
AC
So
as
the
editor
of
the
document,
that's
seventy
five.
Ninety
five
I
think
I
have
that
on
the
next
slide,
you
don't
have
to
yeah
so
2595
as
a
document
says:
here's
the
requirements
for
what
it
takes
to
register
your
I
scheme
so
I'm
the
editor.
If
that
was
that's,
why
I'm
doing
this
one?
Okay
go
ahead
and
next
slide?
Okay.
AC
So
to
summarize
what
problem
this
is
trying
to
address
right,
there's
a
section
that
cumin
that
tries
to
summarize
the
problem
right
and-
and
it's
going
through
to
Rev
so
far
as
I've
captured
more
of
the
discussion
from
and
points
that
people
have
made
on
the
list
or
various
lists
and
I'll
keep
updating
it
as
long
as
there's
new
things
to
add
here
so
today,
there's
lots
of
cases
where
to
you
our
eyes
for
the
same
resource
occur
and
they
differ
in
say.
AC
AC
How
do
I
can
have
values
of
thing
to
say
this
resource
is
more
valuable
than
that
one,
because
this
has
multiple
pages
that
point
to
it
or
multiple
other
resources
that
point
to
it
right
and
so
the
more
aliases
there
are
the
harder
it
is
to
do
certain
higher-level
things.
Okay,
so
I
try
to
capture
that,
and
so
3986
actually
has
this
ladder
level
of
different
types
of
comparison.
AC
Right
I
can
just
compare
strings
or
I
can
have
protocol
scheme
specific
now
I
should
do
a
better
job
of
finding
duplicates
and
so
on,
but
in
general
this
is
allowed,
but
not
sort
of
appreciated
right.
It's
of
minimize,
where
you
can
write
75
95
has
here's
the
requirements
for
a
permanent
scheme
right,
so
URI
scheme
said
permanent
and
provisional
and
75
95
is
what
changed
the
process
for
provisional.
Let's
say
it's
first-come,
first-serve
right.
So
if
you
do
provisional,
you
can
do
whatever
you
want.
AC
It's
just
first-come,
first-serve
IETF
standards
have
to
have
permanence
okay.
So
if
it's
coming
out
of
the
IETF,
you
don't
have
that
choice.
You
have
to
follow
all
the
requirements
and
75
95.
Okay,
now
the
requirements
for
a
permanent,
don't
actually
talk
about
this
particular
topic.
There's
no
explicit
requirement.
Now
it
does
normatively
reference
other
things,
but
there's
nothing.
You
can
really
point
to
that
says:
here's
a
specific
requirement,
and
so
that's
why
it's
fuzzy
and
why
there's
this
debate?
Is
it
a
good
idea?
Is
that
not
a
good
idea?
AC
AC
Okay,
so
in
ocf
they
define
a
higher-level
API
right
if
they're
familiar
with
like
ID
and
locator,
you
can
think
of
this
as
the
ID
right,
no
matter
which
protocol
that
you're
using
to
get
to
it,
no
matter
which
IP
address
it's
at
no
matter
what
port
number
it's
on.
They
have
a
higher
layer.
Api,
that's
unique
for
that
resource.
Okay,
it's
ocf,
colon,
slash,
slash
hash
of
a
public
key
slash
the
rest
of
the
URL
okay.
AC
So
in
their
case,
using
a
hash
of
the
public
key
allows
them
to
cryptographically
bind
the
URI
to
the
to
assert,
that's
being
used
to
authenticate
it
right,
and
so
it
doesn't
have
a
dependency
on
DNS
or
any
PKI.
You
can
use
that,
but
you
don't
have
to
so
that's
why
they
did
that,
but
it
also
follows
the
constraints
of
you
know.
You
want
a
single
unique.
You
arrive
that
the
application
uses
for
a
resource,
ok,
but
you
got
to
have
a
way
of
resolving
that
ID
to
a
set
of
locator.
AC
It's
right,
I
got
to
know
what
the
IP
address
and
the
port
number,
or
which
protocols
the
server's
exported
exposing.
If
there's
multiple
of
them
and
I've
way,
to
know
that
ok
and
so
the
head.
This
way
of
saying,
when
I
learned
that
URI
I
can
learn
the
set
of
locators,
ok
and
in
their
example,
they
said
well,
those
locators.
We
could
use
your
eyes,
we
could
use
something
else
to
the
locator
level.
Ok,
now
some
of
those
might
be
web
sockets,
which
used
URI.
AC
So
they
chose
to
say
we're
just
going
to
use
your
eyes
for
everything
out
of
it
once
they
support
it
and
since
core
was
defining
ones
for
collab,
but
we
got
ones
for
HTTP
and
web
sockets
has
one
I
said
that
should
be
sufficient
to
just
use
your
eyes.
Ok,
as
opposed
to
some
other
way
to
encapsulate
you
know,
port
numbers
and
so
on.
AC
That's
not
me
or
I
syntax,
and
so
when
we
go
through
the
list
of
approaches,
you'll
see
that
this
is
just
an
example
use
case
and
so
there's
various
types
of
resolution
in
the
ocf.
It's
the
way
that
you
get
the
URI.
It
comes
back
with
this
additional
information
sort
of
like
the
additional
section,
DNS
right.
You
might
want
to
have
this
stuff
too,
and
that's
where
you
get
the
locators
from
ok.
Now,
the
in
the
ocf
case.
AC
This
doesn't
happen,
but
unless
you
have
collab
over
things,
but
you
can
actually
head
in
the
more
general
case,
we
have
an
application
in
the
protocol
that
might
be
capable
of
using
two
protocols
in
the
next
lower
layer
and
each
of
them
might
be
capable
of
using
two
things
below.
So
you
can,
in
theory,
have
the
stack
of
stuff,
which
is
hopefully
rare
right.
AC
Most
things
only
have
one
ID
locator
level
split,
but
it's
impossible
to
chain
those
and
say:
I'll
have
an
ID
and
then
I
have
a
locator,
that's
actually
an
ID
that
has
a
locator
below
it
right
and
so
in
more
complex
case,
as
you
say,
well,
I
actually
have
this.
You
know
how
many
levels
of
this
tree
of
locators
needs
to
be
fairly
complex
right.
All
right
now,
ocf
didn't
have
that
problem
if
Co
app
over
TCP
and
co-op
over
UDP
were
compressed
into
one
level
right,
which
is
what
core
was
doing
next
slide.
AC
Thank
you,
okay.
So
some
of
the
discussion
sent
it
sort
of
I
want
to
tease
apart
two
concepts
that
work
here
that
came
up
on
the
various
manless
discussions.
There's
the
concept
of
discovery,
which
is
as
a
client
I,
want
to
just
discover
what
are
the
possible
protocols
and
identifiers
of
those
protocols
by
identifiers
I
mean
things
like
port
number
or
whatever.
The
appropriate
thing
is
for
that
protocol.
AC
How
do
I
discover
what
the
possibilities
are
right,
that
I
call
discovery
versus
selection
I
have
this
set
and
how
do
I
choose,
which
one
I'm
going
to
use?
Okay,
it
was
it
happy
eyeballs
like
thing
where
I'm
trying
things
in
parallel,
where
those
are
too
sore,
thuggin
all
topics
I
got
to
discover
a
set.
Then
I
got
to
have
some
mechanism
to
choose
from
what
then
set
okay
and
it's
really
it's
up
to.
AC
Whoever
is
defining
the
or
I
scheme
to
specify
here's
the
resolution
mechanism
for
discovery
and
here's
where
we
expect
for
selection
constrain,
it's
the
one
to
use
or
whatever.
So
most
of
this
document
is
actually
about
the
discovery
aspect,
but
since
it
was
plenty
of
discussion
about
the
selection
aspect
is
the
little
section
on
there
too.
That
summarizes
the
okay
next
slide.
Okay,
so
the
last
two
slides
links,
I
think
to
the
last
two
actually
summarize.
AC
The
four
different
discovery
approaches
that
are
either
used,
or
at
least
discussed
as
possible
in
theory,
okay,
and
it
enumerates
a
number
of
different
trade-offs
of
each
one
and
sort
of
problems
of
each
one
and
I.
Don't
know
if
there's
any
other
ones
and
there's
probably
other
advantages
and
disadvantages
of
each
one
and
I'm
happy
to
collect
those
and
update
the
document,
as
people
know
more
now
point
out
more,
it's
the
first
category
of
things
is
we're
just
this
URI
scheme
definition
specifies
everything.
AC
AC
They
don't
have
any
higher
of
everyone
right,
and
so
that
was
one
of
the
discussions
around
the
core
working
group,
which
happened
I,
guess
a
couple
days
ago
was
you
know,
should
there
be
a
higher
level
one
or
not?
It's
kind
of
the
open
discussion
that
I
think
will
be
going
on
in
the
core
working
group?
AC
Okay
and
again,
if
you
have
multiple
layers,
there
can
be
complexity
there.
It's
still
possibly
solvable
if
you
have
multiple
layers
of
resolution
or
a
way
to
have
a
stack
of
your
eyes
or
something
okay,
and
if
you
want
to
have
a
different
transport
stack
in
the
or
I
the
only
natural
place
to
put
the
transport
identifier
right
now
is
into
the
URI
scheme.
AC
You
can
kind
of
Packer
on
other
things,
but
the
you
know
that
sort
of
co-op
plus
TCP
is
the
only
natural
way
because
the
the
scheme
is
what
sort
of
identifies
the
protocol
stack
is
the
closest
thing
today
you
like
htps
versus
HTTP,
okay.
So
that's
why
people
do
that,
so
it
kind
of
collects
a
number
of
the
arguments
that
showed
up
around
that
area
and
then
the
fourth
one
is
the
notion.
Well,
why
do
you
need
to
use
a
URI
format
in
the
first
place?
Why
don't
you
use
something
else?
AC
Draft
actually
does
talk
about
that
and
the
argument
for
it
so
obviously
there's
arguments
both
ways
right.
So
the
argument
for
the
anti-pattern
is
once
you
put
it
into
the
path
of
the
query.
That
means
typically
that
that
gets
sent
to
the
server
where
at
the
transport
selection
is
typically
a
choice
made
by
the
client
before
contacting
the
server,
and
so
it
consumes
extra
bandwidth
over
the
wire
okay.
So
that's
the
counter
argument
for
that
one.
But
yes,
that
point
is
actually
talked
about
in
the
document
as
well.
Oh.
N
M
M
AC
Just
repeating
the
point
of
the
document
is
to
not
make
a
recommendation
bush
to
collect
a
lot
of
the
different
ways
that
people
have
proposed,
doing
it
or
are
doing
it
and
to
explain
what
the
trade-offs
are
of
each
one:
okay,
it's
purely
informational
right
now,
okay,
so
the
fourth
category
is
well
for
the
locator
level.
You
don't
have
to
use
a
URI
using
some
other
format
and
not
trying
to
wedge
it
into
the
URI
semantics
right.
You
might
be
using
a
URI
for
the
ID
layer.
AC
You
know
some
common
thing
across
transports,
but
then
you're
using
some
other
format
to
say
where
it's
my
set
of
IP
addresses
and
port
numbers
and
protocol
identifiers,
and
so
on,
something
that's
not
a
URI,
okay,
the
disadvantage.
So
it
has
the
obvious
advantages
which
is
you're,
not
polluting
the
URI.
AC
You
don't
have
multiple
URIs
that
actually
point
to
different
versions
of
the
same
resource
right
and
the
disadvantage
is
just
that
across
those
you
don't
necessarily
have
without
making
up
a
new
one,
a
common
syntax
for
expressing
those
okay
and
so
you'd
have
to
invent
one
of
those.
And
if
you
do
that,
you
can
make
it
work,
okay,
and
so
that's
the
other
approach
that
core
could
have
taken
is
invent
a
new
syntax.
It's
not
your
eyes
that
embeds
the
same
information,
okay
and
so
I
said
well.
AC
Why
am
reinvent
the
wheel
when
we
have
you
know
HTTP
and
we
have
WebSocket
you
our
eyes?
Let's
just
use
your
eyes
for
everything.
That's
the
same
conclusion
that
ocf
came
to
as
well,
and
presumably
what
OPC
came
to
as
well,
which
is
this
didn't
have
advantages.
They
saw
that
we're
significant
compared
to
number
three
okay,
so
that's
the
trade-offs
there
I
think.
That's
my
last
slide.
I,
don't
think
I
have
anything
else
right.
AC
N
I've
had
to
look
for
it
every
time
I
come.
We
do
actually
have
a
document
that
describes
in
really
good
detail
how
to
use
SRV
and
txt
records
for
discovery
and
I,
like
the
idea
of
taking
all
the
cruft
that
exists
and
explaining
it.
But
I
would
like
the
outcome
of
this
to
be.
This
is
how
you
do
it,
because
at
the
moment,
every
time
we
have
a
working
group,
there
is
a
discussion
on.
How
are
we
going
to
do
discovery,
and
that
is
wrong.
Therefore,
a
standards
organization.
N
We
should
actually
decide
on
one
way
to
do
do
discovery
and
instead
of
having
that
discussion
in
different
places
and
coming
to
different
answers,
I'd
like
to
come
to
Wang
agreement
on
how
to
do
it.
I
want
to
have
one
registry
of
identifiers
so
that,
when
I
define
a
webservice,
I
get
my
protocol
name,
and
that
gives
me
the
port
number
equivalent,
because
port
numbers
are
going
way.
It's
given
where
SIV
prefix
it
gives
me
my
well
known
prefix,
gives
me
my
URI.
N
AC
X
I'm,
actually
not
responding
to
Phil
I
just
wanted
to
take
my
time
to
try
to
formulate
a
response.
I
feel
like
I've
gone
back
to
1993,
because
this
is
the
you
are
in
program
problem
over
again
and
that
I
think
the
result
of
that
I'm
very
sad
to
say
he
is
someone
who
put
years
of
my
life
into
that
problem
was
to
create
a
huge
honking
mess,
and
the
most
recent
working
group
in
that
area
completely
did
not
understand
what
it
was
doing.
X
X
Want
to
believe
it's
over
with,
but
it's
not
and
I
don't
want
to
discourage
what
you're
doing.
I
think
what
your!
What
your
approach
makes
sense
is
like
this
is
try
to
sort
of
state
what
this
problem
space
looks
like,
but
there's
something
really
really
dangerous
here.
I
feel
like
a
really
elusive
about
this
problem
space.
X
Then,
when
you
have
you
know
thousands
of
different
people
looking
at
this
kind
of
thing,
each
projecting
their
own
ideas
of
what
they
wanted
to
be
on
that
it's
very
hard
to
create
anything
coherent
out
of
that
so
I,
don't
again,
this
is
nothing
nothing
that
you've
put
up
here.
Is
it
actually,
it
all
makes
sense
to
me,
but
it
made
sense
in
1993,
I
guess
another
thing
that
I'll
say
is:
when
you
define
something
like
that,
you
have
found
define
an
identifier
scheme.
X
Okay,
it
could
be
URI
or
something
else
anyway,
and
then
it
means
something
when
you
define
it
and
then
later
on
in
time,
you
try
to
change
what
it
means
you
try
to
insert
a
layer
of
indirection
you
could
be,
could
be
talking
about.
Ipv4
addresses
and
you
know
originally
ipv4
address.
Was
you
know,
here's
your
it's
Class,
A
or
B
or
C
and
you've
got
this
the
remaining
bits
and
it's
here's
kind
of
the
location.
It
is
in
the
network
and
here's
the
bits
on
that
land
and
then
it's
like,
oh
well.
X
We
have
to
change
how
we
do
the
classes
and
now
we
have
Nats
in
the
way,
and
so
this
just
doesn't
mean
anything
and
every
time
you
have
these
layers
of
indirection,
you
break
things
and
then
so
you
have
this
tension
between
people
saying
no
more
layers
of
indirection,
no
more
raking
things
and
people
saying,
but
we
don't
want
to
change
all
these
existing.
You
know
things
that
expect
this
behavior,
so
we're
going
to
change
it
out
from
underneath
them,
and
hopefully
it
doesn't
matter
so
anyway.
I
guess
I
really
would
like
to
anchor.
X
At
least
you
know
that
the
idea
of
urines
was
we're
going
to
anchor
something
and
say
this
kind
of
scheme
is
distinguished
from
all
these
other
kinds
of
schemes,
so
that
you
can
at
least
tell
the
difference
and
I
still
think
that's
useful,
but
there's
no
way
to
keep
I,
don't
know
how
you
keep
people
from
wanting
to
insert
layers
in
directions
and
the
other
things
I
think
it's
it.
Thank
you.
L
Mark
Nottingham
I
think
that
it
is
entirely
appropriate
for
us
to
be
giving
this
kind
of
advice
and
to
be
thinking
and
talking
about
it.
I
think
there
are
cases
that
are
different
for
different
requirements
for
protocols
that
require
you
know
as
to
treat
people
like
adults
that
that
we
can't
just
say
there's
one
way
to
do
it.
You
have
to
do
it
that
way
or
it's
the
highway
blue
sheets.
Anyone,
yes
and
so
running
this
kind
of
advice
in
this
thinking
and
documenting
these
pitfalls,
or
these
trade-offs
is
important
for
us
to
do
so.
L
I
would
encourage
you
to
continue
and
I
would
encourage
us
to
look
into
this
area.
Thank
you
for
me.
I
thought
we
talked
about
this
briefly
before
I.
I
see
this
as
part
of
a
larger
problem,
which
is
how
do
we
identify
protocols,
because
we
have
many
the
same
uncertainty
and
questions
around
things
like
alt
n
tokens,
which
were
an
artifact
in
TLS
that
suddenly
used
for
lots
of
other
things
as
well?
L
AC
The
audience
of
this
is
sort
of
twofold:
there's
the
ietf
audience,
which
for
standards
anyway,
has
to
do
the
permanent
ones
in
which
you
can
set
requirements
right.
We
can
say
you
have
to
do
it
the
following
way.
If
we
have
things
which
we
say
for
other
organizations
that
don't
have
to
use
permanent,
then
they
don't
have
anything
to
look
at
right
now,
or
at
least
nothing
too
centralized
in
one
place.
It's
get
it
around.
AC
AC
AC
T
T
AB
This
is
Barry.
It
seems
to
me
that
what
we
do
with
it
hinges
partly
on
an
answer
to
Phil's
question,
which
is:
do
we
just
want
an
informational
document
that
gives
what
options
there
are
on
what
the
pitfalls
are?
Or
do
we
really
want
to
come
up
with
an
answer
for
a
BCP
or
something
of
how
you
should
be
doing
it
and
I
lean
toward
that,
which
means
that
just
ad
sponsored
isn't
going
to
do.
AC
D
Adam
Road
I
I
agree
with
that
approach.
I
think
we
probably
want
to
do
here
is
get
input
from
the
art
community
on
the
art
mailing
list
to
see
if
this
is
kind
of
the
right
set
of
things
to
talk
about
again,
not
making
recommendations
as
much
as
just
you
know.
Here
are
the
emergent
properties,
and
then
we
can
circle
back
around
and
determine
whether
one
of
us
will
sponsor
expelled.
Vacation
I.
Think
that's
good.
That
way
forward
here.
AB
AC
AC
D
AD
The
streaming
is
different
can
be
HTTP
or
RTP.
A
distribution
for
type
of
distribution
multicast
for
the
UDP
unicast
it
from
HTTP
ABR
is
something
that's.
Basically,
it's
multi
casting
in
the
middle
for
distributing
long,
video
and
the
devices
can
be
set
up.
Boxes
is
angled
pieces
on
the
on
the
receiving
side.
AD
The
overall
work
where
we
have
to
start
and
prepare
the
content
form
for
this.
All
these
platforms,
you
may
need
to
prefer
prepare
different
packetization
different
delivery
for
the
information
coming
from
the
same
source,
which
makes
it
complicated
on
the
head
end
or
old.
Are
the
equipment
at
the
receiving
side
next
slide
so
the
current
day
transport
protocol?
We
see
those
the
fan
mode,
which
is
mostly
on
the
HTTP.
We
have
pull
or
push
mode
the
codec
the
activation
is
I
am
the
affair
for
mpeg-2
transport
stream.
It's
under.
AD
AD
So
the
impact
of
the
diversity
is
that
fire
mode
is
usually
done,
put
mode
for
push
mode
that
usually
uses
reliable
transfer
protocol
like
no
more
flute
for
multicast
the
part
of
the
of
the
world.
It
usually
applies
most
likely
transmission
to
recover
lost
data,
but
when
does
low
latency,
the
the
relevance
is
sacrificed.
AD
AD
AD
Codec
to
fit
in
the
context
of
a
protocol,
X
RTP
and
the
codec
should
be
authorized
to
be
the
specified
use.
The
you
need
to
do
is
let
the
media
protection
issues
and
other
protocol
is
that
it's
difficult
to
come
back
to
fine
mode
on
the
receiver
side.
If
you
go
from,
if
you
start
five
more
packet
mode
in
the
middle
and
then
we'll
go
back
to
five
more
than.
AD
Next
slide,
so
looking
at
that,
we,
if
you
say
we
described
a
lot
of
a
lot
of
issues,
we
didn't
describe
it.
What
we
really
think
we
want
to
do
here
and
pig
has
done
some
effort
to
provide
convergence
for
this
diversified
situation
in
common
formats.
That's
what
accusation
like
mm
tea
or
simmer,
but
this
is
more
followed.
We
can
see
what
we
can
do.
You
can
simply
transfer
a
one
P
over
RT
p,
but
this
is
that
something
that
put.
AD
With
is
good
enough,
so
the
question
you
ask
yourself
is:
do
we
want
to
work
on
convergence
of
file
and
packet
modes
in
the
IDF
to
2a4
solution
that
we
were
one
of
the
direction
we
looked
in
the
past
and
we
tried
to
look
at
it
is
at
least
for
this
simple,
the
major
problem.
We
see.
We
see
a
lot
of
problem,
day1
transfer
global.
M
AD
He
so
what
we
were
asking
ourself
here
is
that
do
we
want
to
work
on
convergence
of
firing?
Packet
mode
is
some
content.
Agnostic
application
of
an
transport
method
should
be
developing
the
IETF,
mostly
that's
what
we're
talking
about
multi
casting
or
rttp,
who
using
one
is
not
EVP,
and
we
think
that,
if
there's
interest,
we
can
start
discussing
the
issue
of
like
doing
this
week
by
having
some
offline
meeting
and
this
people
very
interested
in
this
work
at
the
ITF
I.
I
AD
Ok,
well,
what
should
we
about?
So
it's
not
necessarily
because
what
we
are
we're
talking
we're
not
only
talking
about
changing
the
terrains,
going
and
learn,
but
even
in
the
middle,
to
try
to
find
a
solution
that
will
help
help
us
with
the
delivery
of
the
video
from
the
centre
side
to
the
receiver
side
in
a
more
optimized
way
than
speed
and
today
so.
O
O
AD
I
think
I
think
one
of
the
issues
we
were
trying
to
encounter
them.
We
try
to
look
at
this
problem
is
that
we
we
need
to
start
with
understanding,
first,
the
the
general
architecture
and
describe
the
architecture
and
what
how
it's
going
through
the
old
the
whole
process
going
from
the
from
the
source
to
to
the
receivers,
and
we
were
we're
not
sure,
even
if
that
sees
things,
that's
being
discussing
the
idea,
because
it's
more
like
a
system
so
motion
on
that
specific
protocol.
AD
So
we
were
running
so
we
can
start
with
games,
providing
some
more
information
about
the
structure
and
where
we
think
we
can
do.
But
we
will
try
to
figure
out
of
those
even
an
interest
to
work
on
this
topic
at
all,
because
if
there's
no
interest
in
doing
anything
in
this
area,
then
why
should
we
start
and
start
to
write
documents
and
try
to
describe
something?
That's,
that's!
Not
a
fair
interest.
Keep.
X
Keep
it
you
know,
I
started
out
thinking.
This
is
mostly
an
impact
problem,
and
then
you
know
I
now
I
think
there
might
be
a
role
for
some
sort
of
collaboration
between
IETF
and
MPEG,
but
at
least
in
my
experience
the
you
know,
it
seems
to
me
from
what
I've
seen
that
MPEG
is
used
itself
in
so
many
different
ways
that
you
know
at
best,
you
could
hope
for
is
a
sort
of
profile
of
impact
that
could
be
used
to
feed
into
you
know.
X
AD
X
AD
Is
that
I
think
that
we
are
not
trying
to
do
to
to
change
what
MPEG
was
proposing?
We're
thinking
that
some
of
the
protocol
and
of
some
of
the
organization
the
template
defines,
makes
sense
to
use
that
we
are
trying
to
see
how
to
transfer
them
in
a
better
way
into
in
the
network
that
that
would
allow
us
to
be
at
better
performance
and
muster.
AD
We
see
this
problem
is
live
video
well,
they
you
have
to
send
a
lot
of
I
mean
you
have
a
moment
and
receive
you're,
seeing
the
same,
the
same
information
and
that
doesn't
address
this
issue
at
all,
I
mean
this
is
things
like
in
fact,
some
some
discussion
was
in
cable
labs,
but
there's
not
something
that
we
can
say.
This
is
the
way
to
do
it
or
thing,
and
maybe
this
is
the
same.
We
need
to
address
here,
but,
as
I
said,
we
need
still
to
start
and
provide
the
whole
view
of
what
is
happening.
D
I
D
AE
Okay,
whatever
okay,
hello,
my
name
is
Frank
Oberg
I'm
from
pretty
easy
privacy,
and
what
we're
actually
doing
is.
We
are
already
implemented
plenty
of
free
software,
which
is
I'm
doing
opportunistic
encryption
of
what
we
call
text
messages.
We
started
with
doing
opportunistic
encryption
of
email
and
now
we're
going
through
travel
to
other
text
message
systems,
and
you
can
download
lots
of
software
there
and
what
we're
doing
is
we
try
now
to
influence
people
that
we
can
make
all
what
we
are
doing
as
no
in
standards?
AE
So
we
are
extra
NGO
and
have
that
idea
and
partly
we
want
of
course
try
to
influence
you
guys
from
the
IETF
that
maybe
you
want
to
have
a
look
on
what
we
are
doing,
because
that's
a
dispatch
session
I
mentioned
things
we
could,
which
could
be
in
the
scope
of
the
IETF
I.
Don't
know,
I
knew
here.
Okay,
for
example,
we
have
protocol
stack,
which
we
call
soon,
which
is
synchronizing
keys
and
trust
between
devices.
AE
So
if
you
have
a
multi
device
set
up,
then
we
are
doing
a
protocol
stack
for
the
synchronization
of
keys
and
trusts,
but
we
also
will
synchronize
addresses,
and
yes,
yes,
Kathy
you
and
internally
in
our
database.
For
for
making
that
happening.
We
have
local
days
of
databases
that
peer-to-peer
100%
peer
to
peer
concept,
so
we
have
always
a
local
database
and
there
we,
unfortunately
using
URI
schemes
which
are
not
standardized
yet
for
things.
We
didn't
find
a
standard
because
we
always
depend
on
common
standards.
AE
I
have
to
mention
that
once
we
depend
on,
for
example,
eg,
P
and
s
man,
and
when
there
is
no
standard,
we
invent
something
our
own.
That
is
basically
what
we
are
doing
and
we
have
identity
management.
We
have
crypto
writing
which
goes
into
user
interface
things,
and
we
have
message
formats
which
we
add
where
we
want
to
add
features
which
are
not
available
in
open,
PGP
NSmen.
AE
So
they
are
commonly
mine
based
and
they
are
some
non
line
based
for
message
transports
where
that
does
not
match
and
we
have
key
mapping
what
we
call
key
mapping
is.
You
can
use
the
same
key
for
s
moment
for
open,
PGP
opportunistically,
and
even
if
there
is
a
message
transport
like
SMS,
which
we
support,
which
is
too
small
for
such
messages,
then
we
have
auto-mapping
on
symmetric
keys
which
are
temporary
okay,
so
that's
different
topics
and
I
would
like
to
be
introduced
where
I
can
address
them.
I.