►
From YouTube: IETF106-DISPATCH-20191118-1000
Description
DISPATCH meeting session at IETF106
2019/11/18 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
A
B
So
this
is
the
note
well,
it
is
a
description
of
the
IPR
practices
that
govern
your
participation
in
this
working
group
and
actually
all
IETF
activities.
It
is
you
know,
Monday
morning
by
ATF,
Week
and
I
see
a
lot
of
familiar
faces,
but
if
you
are
new
welcome
and
make
sure
you,
you
read
up
on
the
privacy
policy
as
well
as
the
IPR
implications
of
this
statement,
I'm
happy
to
talk
with
you
after
the
meeting
about
it
or
you
can
chat
with
one
of
our
ATS.
If
you
have
any
questions,
yeah.
C
A
I'm
gonna,
let
Patrick
do
all
the
talking
from
here.
So
we
have
a
slight
agenda
Bosch.
We
reversed
the
order
of
the
to
dispatch
items
just
because
to
make
sure
we
had
timing,
work
out
and
some
concern
that
rep
might
try
to
steal
time
so
in
unless
anyone
objects
to
that,
we
will
go
with
the
order
on
the
screen,
which
is
slightly
different
than
the
order
on
the
in
the
materials.
A
D
D
D
E
That's
it
from
that
ad,
but
this
is
Barry
Lee,
but
I've
just
but
while
I'm
up
here
after
that
I'll
just
add
my
thanks
to
Mary
as
well.
She's
really
done
a
great
job
chairing
this
over
the
years
and
the
other
thing
I
wanted
to
say
was
we
have.
Thank
you,
the
five
of
you
who
put
your
names
in,
or
at
least
accepted
nominations
for
art
ad.
This
time.
E
Those
of
you
who
are
in
the
room,
Ben
Campbell,
Ben,
Schwartz,
Dave,
Lawrence,
Francesca,
Pullum,
beanie
and
Mary
couch
Ravi.
If
any
of
you
are
in
the
room,
stand
up,
so
everybody
can
see
who
you
are,
as
as
they
follow
the
next
piece
of
what
I'm
going
to
say.
The
NomCom
needs
your
opinions
on
these
people.
Please
go
to
the
NomCom
website
and
in
the
data
tracker
and
log
in
and
give
feedback,
because
that's
how
the
NomCom
figures
out,
who
will
be
best
to
appoint
them?
Yes,
that's
good
Eric
Eric
says
suggested.
F
G
Okay,
hey
guys
I'm,
Shrikant
and
I'm
here
with
my
colleague
Kosta,
so
we're
here
to
present
the
sip
out
of
here
all
right.
So
this
is
what
we're
gonna
cover
in
the
talk
in
the
next
ten
minutes.
I'm
just
going
to
move
on
to
the
first
part
right.
So
the
first
thing
I
want
to
talk
about
is
give
you
basically
a
sense
of
the
problem
that
we're
trying
to
solve
here.
G
What
we've
got
here
on
the
screen
is
a
typical
enterprise
deployment,
with
the
edge
SBC
in
the
middle
talking
to
the
cert
provider,
the
IT
SB,
and
we
are
basically
trying
to
fix
problems
in
that
interaction
in
the
interoperability
between
the
SBC
and
the
itsp.
So
what
we
see
today
is
administrators,
find
it
difficult
to
deploy
these
SBC's
and
get
all
of
the
calls
and
our
use
working.
It
takes
a
lot
of
trial
and
error
to
get
the
working
configuration
right
and
you
know
we
want
to
help
make
their
life
easier.
G
You
know
earlier
we
had
the
legacy
telephony
networks,
analog
and
digital
circuits,
which
were
easier
to
set
up
which
were
quick
and
a
breeze,
and
you
know
you
only
had
issues
in
corner
cases
such
as
hardware
problems.
However,
when
you
come
to
sip
and
RTP,
there
are
a
whole
set
of
parameters
that
are
then
introduced
which
cause
further
issues.
G
So
getting
that
working
config
is
time
consuming
right
and
usually
the
administrators
have
to
open
up
tickets
with
the
HSBC
vendor
and
the
service
provider,
and
then
they
work
together
to
solve
the
problem
and
this
scales
back
the
deployment
times
by
a
few
days.
So
we
want
to
reduce
that
to
a
few
hours
or
even
a
few
minutes.
G
So
the
first
thing
we
had
to
figure
out
was:
you
know
how
much
of
a
problem
this
is
and
for
that
we
went
back
to
our
support
cases
and
we
pulled
the
data
for
a
year
and
over
the
year
we
saw
there's
about
6,000
cases
on
the
SBC
and
about
22%
of
those
cases
directly
related
to
the
SIP
interoperability
problem.
So
if
you
multiply
this,
this
was
on
our
SBC,
the
cube.
G
So
if
you
multiply
this
with
all
of
the
SPC's
that
are
there
out
in
the
market
today,
you
can
see
that
it's
quite
a
significant
problem
that
needs
to
be
solved.
Apart
from
that,
you
know,
a
lot
of
the
telephony
deployments
are
still
legacy
analog
and
digital
circuits
and
people
are
slowly
moving
over
to
SIP
trunks.
So
this
problem
is
not
going
away.
We're
just
going
to
see
more
of
this
and
it's
better
to
fix
this
as
soon
as
possible
right.
So
there
are
a
couple
of
current
solutions
that
are
already
there.
G
The
first
one
is
the
SIP
connect
technical
recommendations.
So
this
is
a
really
good
document
that
provides
a
guideline
to
the
SP
and
the
enterprise
on
how
they
need
to
behave.
It
covers
topics
ranging
all
the
way
from
initial
registration
of
the
device
till
complicated
stuff,
such
as
call
transfers,
call
forwarding
and
even
the
security
aspects
and
how
to
handle
media.
G
So
all
of
this
all
of
these
guidelines
there,
and
even
though
we
have
week
we
can
have
like
you
know,
sip
connect,
sip
connect,
compliant
products
right
today
we
still
see
interoperability,
issues
which
you
know
we
will
cover
in
the
next
slide.
The
second
thing
is
the
service
provided
documentation,
that's
provided
to
the
customer
when
they
buy
the
SIP
trunk.
This
covers
only
high-level
information
such
as
the
authentication,
and
you
know,
a
single
server
IP
that
you
can
communicate
with,
and
apart
from
that,
just
basic
codec
information.
G
Apart
from
this,
let's
say
tomorrow,
there's
a
new
codec
right
or
there's
a
new
parameter,
that's
in
introduced.
There
is
no
way
today,
no
efficient
way
today
for
the
SP
to
inform
the
enterprise
administrator
about
this.
Usually,
what
happens?
Is
the
service
provider
enables
this
new
feature
or
parameter,
and
then,
when
a
call
is
made,
the
call
fails
and
then
there's
troubleshooting?
That
needs
to
be
done
and
that's
when
the
administrator
actually
figures
out
that
hey.
G
You
know
what
this
convict
was
missing
on
the
SVC,
so
we
need
to
start
configuring
the
SBC
this
way
right.
So
here
are
some
of
the
issues
that
we
still
see
today,
which
basically
have
no
answers
right.
So,
for
example,
when
I'm
sending
the
call
to
an
IT
SP
what
happens
if
the
itsp
folks
that
call
right
and
creates
multiple
dialogues
now
as
an
edge
SBC,
do
I
pass
all
of
these
folks
dialogues,
all
the
responses
back
to
the
enterprise
or
do
I
actually
wait
for
a
confirmed
dialogue
before
you
know
letting
the
enterprise
know.
G
So
it
would
be
good
to
be
aware
of
that
fact.
The
second
thing
is
what
about
hairpin
calls,
so
we
have
called
forwarding
and
called
transfer
is
happening
all
the
time
on
calls
that
come
from
the
itsp.
So
when
the
call
is
sent
back
a
lot
of
ideas,
P
is
actually
wait
for
that
first
RTP
packet
to
come
from
the
enterprise
side,
and
if
that
does
not
come
from
the
enterprise
side,
then
they
don't
stream
RTP
either,
and
this
results
in
you
know
a
no
way
audio
or
a
dead
air
issue.
G
G
The
SP
is
reject
that
rien
vite
beyond
a
certain
limit,
or
they
just
reject
three
invite
altogether.
So
that's
another
thing
that
we've
seen
we'd
like
to
know
how
the
SP
routes
calls.
Does
it
route
the
calls
based
on
the
call
party
in
the
to
field
in
the
request,
URI
or
the
P
call
party
ID
header?
So
it
would
be
good
to
know
that,
as
well
as
an
enterprise,
how
do
I
send
the
call
out
to
the
SP
in
the
from
head
of
field?
G
Should
I
give
the
D
ID
number
that
I
bought
from
the
service
provider
or
can
I
just
encode
any
information,
any
user
information?
So
that's
another
important
issue
that
we've
seen
and
finally
now
with
the
rise
of
video
endpoints
on
the
enterprise
side,
we
see
that
a
lot
of
calls
actually
are
sent
with
the
video
em
line.
So
there
are
many
service
providers.
G
They
just
are
okay
with
this
they're,
like
they
just
change
the
video
port
to
zero
and
then
respond
saying
that
you
know
what
I
don't
support
video
with
this
trunk,
but
there
are
others
that
actually
reject
the
call
altogether.
So
again,
it
would
be
good
to
know
this
beforehand
so
coming
to
the
SIP
out
of
here.
G
So
all
of
these
scenarios
that
we've
seen
so
far
right,
we
want
to
be
able
to
give
these
answers
to
the
administrator
the
day
they
are
configuring,
the
SVC
the
first
day
itself,
so
that
they
don't
have
to
go
through
this
trial
and
error
over
days
and
just
try
to
troubleshoot
the
problem
and
basically
make
life
easier
for
them.
We've
encoded.
You
know
the
generic
parameters
that
are
applicable
to
any
SBC
in
a
yang
model.
G
We've
created
the
parameters
and
the
framework
in
such
a
way
that
it
can
be
parsed,
and
this
can
be
automated
so
that
that
there
needs
to
be
no
manual
intervention
by
the
administrator,
so
the
SBC
can
get
the
information
parse
it
and
then
configure
itself
to
get
calls
working.
Fine
right
and
another
thing
is:
we've
covered
from
simple
information,
just
such
as
the
registrar
IP
or
the
call
server
IP
do
something
more
advanced,
such
as
the
RTP
scenario.
G
That
I
was
just
mentioning
in
the
previous
slide
and
finally,
like
we
have
we've,
we've
created
a
data
set
right
of
the
parameters,
but
this
is
by
no
means
the
final
data
set.
We'd
love
some
input
on
this
because
we
want
to
solve
as
many
problems
as
we
can
that
administrators
face
today.
That's
the
goal
of
this
drop,
so
we
are
open
to
input
on
what
we
may
have
overlooked
and
you
know
what
we
could
add
and
what
we
could
refine
in
that
capability
set
all
right.
G
So
this
is
a
high-level
overview
of
what
exactly
the
draft
does
right.
There
are
just
four
steps.
The
first
step
is
that
the
SBC
gets
the
information
of
the
capability
server.
That's
the
new
element
on
the
SP
network.
It
just
has
to
be
a
web
server
right,
that's
hosted
by
the
SP
with
the
required
capability
set
information.
The
HSBC
gets
this
information
and
you
can
either
manually
provide
it
or
it
can
be
discovered.
It
can
be
discovered
right
on
its
own
once
it
gets
that
URL.
G
It
goes
ahead
and
sends
an
HTTP
GET
for
the
capability
set.
It
gets
the
information
in
the
response
and
once
it
gets
that
response
it
parses
it
and
configures
itself
or
an
administrator
can
go
through
that
and
configure
the
SBC
as
required
right.
So
the
first
thing
is:
why
HTTP,
because
why
not
HTTP?
Because
it's
it's
the
most
common
protocol,
it's
well
established.
G
You
know
it's
the
path
to
least
disruption.
You
don't
have
a
chain
we're
not
trying
to
change
the
sip
stack
here,
because
that
would
be
a
mess.
So
HTTP
is
much
easier
to
implement.
That's
why
we've
gone
ahead
with
HTTP
and
apart
from
that,
most
SBC
is
today
already
have
an
HTTP
stack
built
in.
So
all
you
need
to
give
is
that
URL
and
then
they'll
go
ahead
and
query
the
HTTP
server.
G
Apart
from
that,
you
know,
there's
no
point
of
querying
the
capabilities
once
the
trunk
is
registered
between
the
service
provider
and
the
HSBC,
because
in
order
to
get
that
registration
up,
you
also
need
to
provide
information
such
as
where
the
registrar
server
is
and
what
the
credentials
are,
so
that
kind
of
defeats
the
purpose
right.
So
the
second
question
that
we
had
is:
how
do
we
encode
this
data
right?
So
we
are
like
on
the
fence
about
this,
whether
we
should
go
with
XML
or
JSON,
because
both
of
them
have
their
pros.
G
Xml
is
synonymous
with
configuration
files
today,
so
most
I
guess
pcs,
except
xml's
in
the
form
of
a
document,
and
then
you
know
configure
themselves
based
on
that,
so
they
have
a
parts
are
built
in.
You
also
have
xml
schemas.
That
has
strong
constraints.
The
only
problem
is
that
it's
bulky
and
verbose,
and
you
know
you
have
to
convert
a
document
to
a
data
structure,
but
that's
ok.
We've
we
have
code
that
does
that
already.
On
the
other
hand,
json
is
compact.
G
It's
readable:
it's
already
data,
that's
formatted
as
a
map
right,
so
it
has
a
bunch
of
advantages
going
for
it.
It's
just
the
only
weakness
it
has
is
you
know
it
can't
deal
with
unstructured
data
that
well,
but
that's,
ok,
again
right
so
in
this
draft,
we've
tended
to
go
towards
XML,
just
because
we've
seen
it
more
in
action,
I'll
be
showing
an
example
of
that
capability
document
in
a
future
slide
right.
So
the
next
thing
is
the
yang
model
that
we've
defined
in
this
draft.
G
G
Also
apart
from
this,
the
good
thing
about
using
a
yang
model
is
that,
even
if
the
service
provider
wants
to
encode
vendor
specific
information,
they
can
just
import
this
yang
model
and
then
build
on
top
of
that,
so
they
can
add
their
vendor
specific
information.
On
top
of
that,
all
right.
So
here's
the
example
of
what
the
document
looks
like
again.
We
went
with
XML
just
because
we,
you
know,
we've
seen
more
of
it.
G
That's
all,
but
we've
not
made
a
final
decision
that
it
is
going
to
be
XML,
we'd
love
to
hear
pointers
on
which
would,
if
JSON,
would
still
be
better
I'm
not
going
to
go
through
all
of
the
fields.
This
is
just
a
slide
to
show
what
it
would
look
like.
So,
as
you
can
see
you
know,
all
of
the
important
parameters
are
there,
and
this
is
something
that
the
SBC
could
just
parse
on
its
own
and
configure
itself
all
right.
So
the
way
forward.
G
So
that's
who
we're
targeting
here
and
that's
who
we
want
to
make
life
easier
for
so
we
love
your
inputs
on
refining
the
capability
set,
and
you
know
anything
that
we've
overlooked.
We've
got
to
get
help
page
and
you
know
we'd
love
to
hear
your
inputs
there
and
yeah
I'd
like
to
open
up
to
the
group
as
to
how
the
draft
should
be
taking
forward
as
well.
Thank
you.
A
So
in
light
of
not
everyone
jumping
to
the
mic
first,
does
anyone
have
any
questions
about
the
content
of
the
draft
or
technical
questions
or
comments
and
I'm
not
seeing
anyone?
So
then
do
people
have
opinions
on?
What
do
we
do
with
this?
Is
this
something
that
the
IETF
should
progress
and
if
so,
what's
the
best
way.
H
So
Hoss
I
think
the
problem
being
listed
is
something
that
we
have
come
across
earlier
in
deployments
and
I
definitely
think
we
should
spend
some
time
solving.
This
graph
proposes
one
way
we
might
have
to
probably
think
about
what
are
the
parameter
sets
that
there
and
what
are
the
defaults
that
we
can
also
provide
so
that
you
know
it's
easy
to
Auto
configure
if
needed
and
I
totally
agree
there.
There
are
some
cases
where
manual
intervention
is
required.
G
B
K
B
A
This
has
been
Campbell
pretending
to
be
from
the
floor.
Oh
I'm,
sorry
go
ahead,
Ted
and
you
were
in
line
before
me.
Go
ahead.
I
was
just
going
to
ask.
What
are
your
thoughts
on
how
fixed
this
capability
set
will
be
over
time?
Do
you
see
it
changing
much
as
you
find
new
areas
of
incompatibility,
or
are
we
talking
about
the
same
set
of
injuries
that
are
pretty
much
done
and
not
changing
stuff?
So.
L
M
Saturday
in
in
the
chapter,
we
were
sort
of
trying
to
figure
out.
If
this
looked
more
like
it,
it
belongs
in
one
of
these
groups
or
needed
new
place
to
go,
and
one
of
the
questions
I
had
was
whether
or
not
it
were
a
new
place,
whether
belonged
in
this
area
or
in
ops,
slash,
network
management
and
so
I.
Think.
M
M
D
Alexei
Melnikov
has
one
of
our
Taiji's.
We
just
had
a
quick
informal
discussion
between
80s
I
think
it
probably
makes
sense
to
have
a
mini
working
group.
I
think
we
should
keep
the
dad's
question
in
mind
and
our
tidies
probably
can
talk
to
ops
and
management
AG's
and
see
whether
this
will
land,
but
for
me
personally,
not
being
a
sip
expert
or
anything.
It
seems
like
a
reasonable
problem
to
solve
and
seems
like
a
reasonable
area
to
bring
this
to.
So.
N
L
So
we
we
realized
that
the
sit
connect,
or
rather
the
crux
of
the
SIP
Connect
recommendation-
is
to
actually
smooth
and
interrupt
between
enterprise,
vendors
and
service
providers.
So
the
direct
answer
to
your
question
is
no:
we
haven't
had
any
dialogue
with
folks
from
sip
connects.
However,
we
look
at
this
as
pretty
much
a
complementary
effort,
something
that
actually
complements
that
connect
and
makes
lives
easier
for
administrator's.
A
O
Chris
went
I
guess
my
only
comment
is
I
wonder
if
this
is
too
little
too
late,
like
you
know,
is
SIP
connected.
It's
it's
good
it.
What
didn't
catch
on
like
wildfire,
I
know
like
generally
when
our
customers
connect
with
PBX
is
it's
sort
of
like
you
know,
just
painful
enough.
That
makes
our
life
hard,
but
not
painful
enough.
That
I
mean
anybody
wants
to
really
change
it
and
type
of
thing.
O
G
Yeah
I
just
want
to
add
on
to
that.
So
another
thing
is
that
you
know
we
see
that
solution.
Test
teams
today
have
a
huge
backlog
of
testing
because
of
this,
because
they
have
a
test
with
multiple
providers
and
we're
just
gonna
see
more
people
migrating
to
sip
in
the
coming
years.
So
this
is
gonna
become
a
bigger
problem.
So
maybe,
when
it's
a
bigger
problem
than
people
might
care,
but
point
is:
let's
fix
it
before
it
becomes
that
big
problem.
N
Jonathan
is
relaying
for
Mary
Barnes.
She
says
giving
her.
We
could
never
get
folks
to
even
agree
on
basic
sip
device
configuration
I'm,
not
sure
this
will
get
anywhere.
Not
that
I,
don't
think
it's
a
good
idea
and
step
four
I'm
tried
to
do
device
configuration
couldn't
get
traction.
This
might
be
a
good
thing
to
see
if
we
get
a
bavitz
if
knock.
L
So
I
I
think
in
our
personal
opinion,
it's
not
so
much
as
configuration
as
much
as
discovery
of
or
whatever
it
is
that
the
service
provider
does
doesn't
do
like
does
like.
We
are
not
advocating
for
the
service
provider,
for
example,
to
push
configuration
to
the
SPC.
What
we
are
advocating
for
is
the
administrators
who
have
as
much
knowledge
as
possible
on
day
zero.
A
So
this
has
been
Campbell
from
the
floor
and
then
at
the
chair
in
just
a
second
from
the
floor,
I
would
say
one
of
the
things
I'm
kind
of
hearing
the
discussion
is.
It
would
be
good
to
have
him
input
from
the
peep.
They
wouldn't
implement
this
to
make
sure
they
really
would.
That
would
be
both
the
service
providers
and
the
specie
vendors,
and
since
we
only
had
half
a
hand
on
the
SBC
vendors
earlier,
we
don't
really
have.
We
don't
know
the
answer
to
that
right
now,.
G
A
Okay,
I
think
a
little
bit
of
summarize
a
summary
of
what
I
heard
and
people
feel
free
to
interject.
If
I
have
some
of
it
wrong.
Is
the
people
think
in
general,
this
is
probably
worth
doing.
There's
some
concerns
about
whether
it
would
be
used.
If
we
do
it,
we
think
that
it
needs
coordination
with
the
people
that
would
actually
implement
it
and
deploy.
Yes,
thank
you
and.
A
The
area
directors
have
talked
about
it
and
consider
that
it
might
be
worth
a
mini
working
group
and
it
it's
not
clear
if
it
belongs
in
art
or
UPS
or
straddling
the
borders
of
those,
and
that
actually
reminds
me
of
one
question
I
meant
to
ask
a
minute
ago,
since
the
80s
made
the
comment,
this
might
be
moot.
But
since
you
brought
up
zip
core
I
think
we
have
a
support
chair
in
the
room
Brian,
you
have
any
thoughts.
P
We
certainly
could
do
this
in
succour
and
I
wonder
if
it
is
worth
spending
up
as
a
mini
group
for
it
I'm
on
the
on
the
bubble.
The
workload
right
now
is
moderate,
so
timewise
we've
got
time.
You
got
shares
and
infrastructure
and
all
the
people
you
really
want
to
review
are
there.
So
the
advantage
of
going
doing
it
in
succour
is
you've,
got
this
ready,
review,
crew
and
there's
enough
time
to
do
it.
P
Q
Actually
I
can
say
is
this:
is
Adam
Roach
that
yeah
we
probably
would
want
to
like
adjust
the
Charter,
and
if
we
see
if
we
see
like
the
paces,
that's
going
on
and
set
course
staying
the
same
way.
It
is
and
more
things
like
this
coming
along,
we
might
want
to
sort
of
loosen
things
back
to
the
way
they
were
back
when
it
was
set.
S
R
Peterson,
by
the
way
there
was
a
working
group
called
modern
which
actually
still
exists.
It
still
exists
in
part
because
I
insist
that
it
be
kept
on
life
support
because
we're
gonna
need
it.
Oh,
my
god,
there's
like
all
this
configuration
stuff
related
to
like
stir
and
all
these
things
that
we're
gonna
have
to
do
at
some
point
and
we're
just
too
busy
doing,
stir
and
shakin
and
everything
in
the
moment,
but
it
does
exist
as
a
bucket
and
Steve
Donovan
was
sitting
over.
There
is
still
a
Stuckey
responsible
for
it.
R
N
N
E
And
this
is
Barry
liebe
I
said
Minnie
Minnie
working
group
to
start
with,
when
Brian
suggested
you
doing
in
sip.
Core
I
was
good
with
that.
Mary's
point
is
well-taken.
We
could
certainly
draw
the
right
ops
people
in
for
the
discussions,
but
it
might
be
better
to
have
a
mini
working
group
to
highlight
that
and
actually
assign
an
ops
advisor
or
something
so
I'm
ambivalent,
that
what
Mary.
J
A
E
A
Q
A
Because
it's
Monday
morning
go
ahead:
okay,
hey
aunt
Colin's!
Next,
because
this
Monday
morning
and
the
chairs
weren't
on
our
ball
on
the
ball.
We
forgot
to
send
out
the
blue
sheets
at
the
beginning
of
the
meeting,
so
we
sent
it
out
kind
of
in
the
middle
of
that
discussion
with
no
words
so
or
no
words
for
us
about
it.
So
if
anyone
forgot
the
blue
sheets,
please
looks
like
we
got
it
covered.
Okay,.
J
Okay,
I'm
here
to
talk
about
this
rip
protocol,
which
has
very
little
to
do
with
the
previous
presentation
at
all,
but
it
is
about
connecting
up
voice
and
possibly
video
things
between
different
services
and
making
this
easier.
So
there's
you
know
a
bunch
of
co-authors
on
this
is
very
early
work.
It's
not
like
all
of
us
agree
on
any
of
this
or
anything
or
just
that
the
ideas
are
gelling.
J
J
So
what
we're
trying
to
do
I
mean
you
know.
This
is
similar
to
step
trunking
right,
there's
all
kinds
of
cloud
services,
whether
they're
WebEx,
whether
they're
call
centers
whether
they're
hangouts
meeting
conferencing
systems,
which
initially
are
just
trying
to
connect
clients
and
then
connect
to
the
PSTN.
So
this
work
started
with
a
very
much
of
PSTN
focus.
What
do
we
need
to
do
to
make
it
easy
to
cross
across
to
a
service
provider
that
has
PSTN
gateways
and
make
that
work
now?
J
You
know
Justin
very
much
feel
strongly
we'd
like
to
be
able
to
use
it
from
end-user
clients
to
the
cloud
and,
along
with
that,
comes
a
much
stronger
desire
for
it
to
support
video,
not
just
audio,
because
it's
not
just
a
PSTN
Interop
solution
and
also
brings
to
make
you
know.
Ups,
the
the
requirements
framed
in
security
and
stuff
like
this,
so
that's
that's
how
the
problems
expanded
since
so
I
talked
about
this
four
months
ago.
J
They
all
leverage
HTTP
as
a
really
good
way
to
provide
a
lot
of
services
to
build
very
stateless,
highly
distributed
highly
reliable
services
and
sips
really
a
bad
match
to
them.
If
you
try
and
deploy
sip
in
an
AWS
data
center,
you
get
basically
nothing.
You
get
largely
some
raw
metal
that
you
can
run
your
stuff
on
where,
if
you
could
have
a
way
to
do
a
lot
of
these
same
types
of
things
over
a
mechanism
that
looks
very
much
like
a
HTTP,
you
could
leverage
an
incredible
amount
of
infrastructure.
J
That's
been
built
to
do
that
and
and
do
a
much
better
solution,
and
that's
really
what
we're
proposing
here
is
to
to
move
to
that
type
of
environment.
We
can
take
advantage
of
that
so
use
cases,
some
of
the
ones
I
talked
about
a
straight
up,
but
you
know
you're
running
a
large
cloud
data
center
and
you
want
to
be
able
to
take
advantage
of
of
those
types
of
environments
for
PSTN
interconnect.
Ok,
I!
Don't
really
talk
about
these
use
cases
too
much.
J
You
know
so
the
SIP
trunking
those
come
up
in
all
kinds
of
different
cases.
We
have
a
lot
of
things
that
are
difficult.
What's
it
both,
like
you
know
as
you're,
trying
to
just
run
VMs
and
tear
them
down
and
bring
them
up
for
reloads
of
software,
or
whatever
reasons
does
not
have
a
lot
of
support
built
in
for
those
types
of
management
exercises
or
high
liability
exercises,
where
you
can
do
it
without
ever
degrading
your
service.
J
Yes,
people
have
managed
to
build
incredible
SPC's
that
can
hide
some
of
this
and
make
it
do
and
work
in
a
high,
reliable
way.
But
it's
it's.
The
protocol
was
never
really
designed
very
well
for
that
it
wasn't
one
of
those.
The
things
was
trying
to
do,
and
it's
very
difficult
to
do
also
interested
in
just
straight-up
enterprise
voice,
trunking
and
making
that
very
simple
and
easy
to
deploy
a
lot
of
those
types
of
things.
J
That's
expanding
rapidly
right
now,
I
I
didn't
mention
it
here,
but
there's
also
a
lot
of
use
cases
around
speech,
recognition,
services,
so
speech.
Recognition
right
now
has
taken
off
like
crazy,
largely
due
to
ml
approaches
to
it,
and
the
ML
approaches
require
an
incredible
amount
of
data
to
train
against,
and
the
people
that
have
huge
amounts
of
data
often
have
the
best
speech
recognition
systems
because
of
the
data
they
can
bring
to
bear
on
the
problem.
J
So
you
see
that
with
lots
of
people
trying
to
use
a
small
number
of
large
cloud
providers,
speech
recognition
systems
because
they
basically
do
better
than
more
just
ones
that
aren't
large
cloud
Suns
and
we
don't
have
particularly
good
ways
if
you
go
to
cross
the
api's
across
all
the
vendors
I'm,
not
picking
on
anyone.
It
is
that
the
streaming
API
is
for
streaming.
Real-Time
reking
voice
recognition
across
every
vendor
right
now
leave
things
to
desire.
M
Better
tea
with
a
clarifying
question
when
you're
talking
about
speech
recognition
here,
obviously
a
lot
of
that
is
also
moving
on
to
devices
at
the
moment
with
specialized
systems.
Are
you
particularly
concerned
with
cases
for
the
speech
recognition
where
there's
some
other
process,
which
occurs
after
speech,
recognition
like
IVR
or
translation
to
a
secondary
system,
or
are
you
really
concerned
with
speech
recognition
itself
because
I'm
yeah?
That's.
J
That's
a
good
question,
so
look
if
the
speech
recognition
happens
on
device
that
solves
a
lot
of
privacy.
Problems
is
great
for
many
cases,
but
if
you're
building
a
small,
you
know
if
you're,
a
small
startup
company
and
you're
building
a
contact
center
based
on
top
of
say,
you
know
Twilio
xapi
eyes
or
somebody
like
that.
M
J
J
So
in
any
one
of
these
calls,
they
have
you
know,
sort
of
there's
someone
at
the
beginning,
maybe
it's
offline
ahead
of
time
or
but
there's
there's
a
way
of
understanding
the
capabilities
of
both
systems
at
some
level,
there's
a
way
of
setting
up
a
media
flow
and
saying
what
actual
capabilities
you're
using
you
know.
This
is
Opus,
or
this
is
jisub
on
the
the
facts
about
it.
There's
some
event
notification
back,
particularly
we're
talking
about
PSTN
are
off
call.
J
You
know,
calls
ringing
the
calls
answered,
those
types
of
ideas
and
I
and
I
think
that's
you
know
it's
one
of
difficulties
is
the
way
that
was
mapped
into
sip
wasn't
really
ideal.
It
was
was
always
confused
with
how
the
billing
was
going
to
work
and
then
there's
the
actual
media,
audio
and
DTMF,
and
video
is
what
this
is
expanding
into,
or
the
the
key
ones
we're
thinking
about
right.
Now.
J
The
capabilities
there's
some
proposal
in
this
document
for
just
a
simple
way
to
do
capabilities,
I'll
talk
about
range
of
different
ways.
We
might
solve
that
right
now.
I
am
arguing
very
much
for
a
wholesale
replacement
of
SDP
to
something
much
more
much
simpler,
based
on
the
work
that
John
and
I
did
very
many
years
ago
on
advertisement.
Proposals
justin
is
at
the
far
end
of
spectrum
from
me
as
usual,
and
he
is
our
before
we
totally
use
sdp
offer
answer.
So
if
this
strikes
anyone
is
funny
it
strikes.
J
Both
of
us
is
funny
because
it's
a
180
from
where
we
were
on
web
RTC,
but
you
know,
there's
some
range
of
those
and
in
between
I'm
gonna
skip
the
slide.
A
caller
ID
right
now,
we're
just
passport
seems
to
be
the
thing
we're
looking
at
open
to
other
ideas
there,
but
we
need
some
identity
mapping.
The
protocol
mapping
there's
some
some
rough
proposal.
How
to
move
this
into
HTTP
like
requests
where
you
can,
you
know,
have
objects
representing
calls
and
stayed
in
information
about
that.
J
I
would
views
all
of
this
right
now,
as
you
know,
a
laughable
straw,
man
at
the
beginning
of
it,
and
we
need
to
so
refine
that
and
bring
that
in.
But
we
want
the
point
here
is
we
want
to
do
it
in
a
way
where
we
can
take
advantage
of
all
the
ways
we
build
modern
applications
in
HTTP
based
data
centers
and
take
advantage
of
the
infrastructure
that
there's
they
use
it
and
make
sure
we
can
use
those
for
voice
calls
not
just
other
applications.
J
The
media
by
ways
was
oleh
to
send
real-time
media,
both
directions
by
striping,
multiple
transactions
over
an
HTTP
connection,
I
I
think
this
was
a
an
initial
sort
of
stab
at
something
to
get
something
down.
But
I
really
think
that
if
the
web
transport
stuff
goes
well
this
week,
we'd
probably
move
to
something
like
that.
I,
don't
think
any
of
us
are
very
are
thrilled
with
this
exact
design.
If
we
can
figure
out
something
better,
Jonathan
Rowland
largely
wrote
this
up
to
show
that
that
something
is
possible.
J
Like
here's,
here's
proof
of
existence
of
we
could
do
something,
and
you
know
variations
of
this
have
been
implemented
by
meander
mini
voice
over
IP
systems
over
the
years.
So
it's
not
like
there's
not
much
to
invent
here,
but
we're.
You
know,
I,
think
that
the
desire
is
moving
to
something
largely
running
over
quick,
because
we
believe
quick
will
be
supporting
the
data
centers
with
probably
unreliable
transactions
which
we'd
like
to
see
going
there.
So
that's
that's
where
we're
thinking
on
some
of
that
transport.
J
J
Where
then,
all
security
ended
so
that
one
hop
was
already
secured,
the
Indian
wasn't
gonna,
buy
you
anything
there,
and
so
you
know,
but
as
we
move
to
using
it
down
to
clients
and
expanding
out
the
use
cases
for
use
in
in
downed
clients
and
a
broader
sort
of
things
in
video,
then
clearly
some
sort
of
Indian
security
needs
to
be
put
in
here
rough
thinking.
Right
now,
people
been
sort
of
vaguely
talking
about
the
ideas
of
MLS,
but
we
need
a
clear
identity
mechanism.
J
J
So
this
is
what
questions
where
I'd
love
love
some
feedback.
You
know
the
the
problem.
Scope
is
the
biggest
thing
right
now
when
we
originally
thought
about
this.
We
were
thinking
only
between
data,
centers
and
PSTN
gateway
providers,
and
and
it
was
for
PSTN
on
ROM.
Now
we've
expanded
that
out
quite
a
bit
for
like
the
speech
recognition
case
and
we're
talking
about
moving
out
to
audio
and
video
and
also
to
endpoints.
T
O
Chris
when
Chris
went
I
think
you
know,
I've
been
thinking
about
this
stuff
in
multiple
contexts.
We've
been
talking
about
video
relay
services
like
in
FCC
context,
we've
been
talking
about
you
know,
just
like
a
lot
of
people
are
building
web
RTC
gateways
that
support
audio
and
telephone
calls
and
other
things
like
that.
I
think.
The
fundamental
problem
is
that
video
has
turned
out
to
be
pretty
much
multi-party
context
with
no
features,
no
application
features.
But
we
have
this
thing
and
the
PSTN
side,
where
for
enterprise
telephone
calls
for
any
complex
thing.
O
We
have
all
these.
You
know
diversion
all
this
stuff,
you
know
and
and
when
you
talk
about
like
Enda
and
security
and
all
this
stuff,
if
you're
passing
calls
like
all
over
the
place
and
it's
being
forwarded,
it
just
like
becomes
a
complete
mess.
So
you
know
in
the
way
that
we've
implemented
things
we
sort
of
try
to
abstract
that
stuff.
But
the
problem
is
the
applications
sort
of
like
you
have
the
N
and
I
on
one
side.
O
You
have
the
applications
and
the
network,
and
then
you
have
you
know
the
essentially
pure
connection
thing
that
goes
from
the
application
to
the
actual
endpoint
and
your
and
at
the
end
of
the
day.
That's
just
about
media
I
mean
there
is
the
other
complication
of
terminals
that
actually
implement
applications
as
well
and
other
things
like
that.
But,
like
I
think
you
know,
I
haven't
really
scoped
that
too
well,
but
I
think
that,
hopefully,
that
illustrates
part
of
the
problem
I
think
we're
facing.
U
So
this
feels
a
little
like
fighting
a
lost
war.
So
when
you
know
when
SIPP
was
like
first
designed,
you
know
it
was
designed
as
a
quasi
like
decentralized.
U
You
know,
quasi
peer-to-peer
system
or
centralized
signaling
and
that
didn't
work
out
like
as
well
as
we
were
hoping,
and
we
kind
of
got
like
centralized
like
everything
and
like
I
can
certainly
see
like
one
would
have
the
urge
to
be
like
well,
let's
just
like
declare
defeat
and
be
like,
let's
say
I
like
centralized
everything
and
you
know
in
design
a
system
which
doesn't
have
any
of
those
mechanisms
centralized
but,
like
you
know,
Simon,
to
do
that
at
the
same
time
has
like
you
know
as
like,
the
PSTN
is
dying
and
like
over
the
top
is
taking
off,
and
an
end
in
encryption
is
like
more
important
than
ever.
U
I
mean
just
seems
like
like
this
is
the
design
you
like?
One
might
have
one
would
have
done
20
years
ago,
and
now
we're
talking
having
this
design
now
and
not
having
a
like
design,
which
is
like
endpoint.
First
now,
just
like
seems
either
one
direction
so
I
mean
if
you
will
design
like
some
new
thing,
that,
like
uses
quick
and
like
you
know,
and
and
and
it
is
you
know
and
doesn't,
use
STP
or,
like
you
know,
doesn't
use
a
circular
or
whatever.
J
U
J
U
U
Part
I
mean
right;
this
is
just
this
is
just
designed
as
AI
star
configuration
I
clearly
show
yeah
totally
yeah,
yes,
but
the
fact
that
then
it
also
has
like
hand-wave
may
be
inserted
in
encryption
here,
like
is
like
a
little
stretching
as
well
right.
So.
J
N
Jeff
Lennox
on
the
question
of
just
audio
or
audio
and
video
I,
think
a
lot
of
the
reasons
why
video
you
know.
The
lot
of
things
that
make
video
so
annoying
in
both
RTP
and
SDP
is
that
they
were
both
designed
with.
Let's
do
audio
first.
We
understand
that
and
we'll
retrofit
video
later,
and
it
turns
out
that
video
is
very
different
and
you
know,
has
a
lot
of
new
requirements
and
retrofitting
them
on
is
hard,
so
I
would
say
either
design
us
with
video
from
the
beginning
or
explicitly
to
care
video
out
of
scope.
R
John
Peterson
and
I
love
when
the
ITF
divides
things
into
you
and
I
and
and
I
finally
feel
at
home
here
in
the
ITF,
and
that's
actually
what
I
guess
I
wanted
to
say
about
the
first
bullet
here
I
mean
I.
Think
if
you're
gonna
do
this
and
just
declare
an
and
I
which
one
could
maybe
something
that
might
soften
the
blow
of
Becker's
despair
there
is.
It
have
any
at
least
some
requirement
for
what
you
and
I
would
be.
R
That
would
then
interface
with
this
in
a
way
that
would
enable
and
end
security
without
necessarily
being
prescriptive
about
what
that
uni
interface
is
going
to
be
because
the
Chris
Ben's
point
I
mean
it's
very
pluralist.
It
could
be.
You
know,
Weber
Kesey
or
something
right
that
is
connecting
up
to
WebEx
and
then
WebEx
is
talking
across
the
Comcast
and
I
can
imagine
there
being
an
N
and
I
as
much
as
you
know.
P
Brian
Rosen
I
I
have
this
feeling
when
you
got
up
here
and
said:
oh
now,
we're
gonna
talk
about
endpoints
that
this
is
sip
3.0
I
mean
where
you're
talking
about
redesigning
the
protocol
for
creating
multimedia
connections
across
the
internet,
and
it
might
really
be
time
to
talk
about
that.
I'm
I'm,
not
afraid
of
opening
that,
but
what
I
am
afraid
of
is
side
stepping
into
it,
because
that's
what
we
did
was
set
and-
and
we
didn't
say
no-
we're
really
talking
about
a
protocol
for
doing
multimedia
communications
over
the
Internet.
P
V
That
would
that
we
think
lies
in
STP
and
separate
things
like
that
is
not
really
just
syntactical
ugliness,
there's
a
lot
of
complication
that
an
endpoint
specific
audio
formats
or,
if
you're
talking
about
just
going
to
a
you,
know,
I
TSP,
there's,
usually
a
very
simple
set
of
rules
that
you
could
use
and,
and
you
could
standardize
it
and
that'd,
be
easy.
V
Adding
in
points
to
the
mix
to
allow
you
know,
endpoint
to
endpoint,
even
communication
that
greatly
expands
the
universe
of
of
codecs
and
formats
and
and
and
and
when
you
add
video
another
two
to
four
X
Factor.
So
I
think
it's
good
to
keep
those
in
mind.
But
somebody
has
to
be
conscious
that
this
is
easily
a
four
to
eight
X.
You
know
amount
of
effort
for
adding
those
things
in
the
scope.
U
Aircrew
scroll
again
so
I
mean
I
guess
this
is
dispatch
not
often
so
usually
that
is
our
call.
John
Wooden
culpa,
don't
I
do
but
the
you
know
the
usual
things
here.
Are
you
know
this
should
be
a
be
sponsored
killer?
Will
fire
this
should
be
a
t
sponsored
there
should
be
a
buff
or
ticketing
working
group
I.
Think
clearly
like
we
can't
be
any
sponsoring
this,
like
that's
like
way
too
big
I
can't
go
missed
you
working
coop.
Also,
we
can
make
I,
don't
think
his
bite.
U
My
my
concerns
earlier
I'm,
not
sure
I,
didn't
say,
kill
it
with
fire.
So
I
think
the
only
plausible
outcome
on
here
is
you
need
to
like
he's
like
you
know.
You
know
like
put
together
a
buff
puzzle
for
like
the
next.
You
know
next
idea
right
or
some
future
IT
effort.
I
guess
forgive
you
mailing
list,
I.
J
Had
a
couple
more
slides
on
this,
but
I'm
not
I,
think
that
we're
actually
getting
the
heart
of
at
what's
the
actual
important
part
of
things
to
discuss
right
now,
so
I'm
fine
with
the
discussion
we
can
and
wherever
we
need
to
end
and
I
I
as
clearly
to
me,
it
needs
to
be
a
working
group.
I
totally
agree
on
I.
J
U
A
One
comment
from
the
chariot
this
has
been
the
one
thing
I
think
Edgar
left
out
of
this
list
is
that
we
can
dispatch
things
directly
to
a
mini
working
group
or
that
sort
of
thing,
or
even
a
full
working
group
and
bill
charter
working
here.
If
the
eighties
want
to
do
it
that
way,
but
I'm
not
saying
that's
what
we
should
do,
but
it's
still.
J
W
On
that
note,
mark
Nottingham,
so
are
you
giving
up
in
your
presentation
or
is
there
more
to
come?
I
have
a
more
general
comment,
I'm
happy
to
wait,
I'm
happy
to
do
it.
I'm.
B
B
W
W
So
we
have
this
draft
in
in
HTTP
working
group
called
BCP
56
bits.
It
is
surprisingly
a
revision
of
BCP
56,
which
is
how
to
use
HTTP
as
a
substrate
for
transfer
for
application
protocols,
and
it
is
attempting
to
give
advice
and
best
practice
for
how
you
build
something
on
top
of
HTTP
to
get
the
most
out
of
the
infrastructure,
which
sounds
like
what
you're
trying
to
do
and
document
well-known
pitfalls
and
so
forth.
I
would
love
it
if
this
were
to.
W
W
You
know
just
report
back
and
that
would
help
us
make
sure
that
that
document
is
is
doing
the
right
thing,
because
we're
seeing
more
and
more
we've
talked
about
this
before
we're
seeing
more
more
protocols
using
HTTP,
they're
kind
of
all
over
the
map,
and
so
we
need
to
document
these
practices.
We
think
it's
done
we're
just
waiting
for
the
HP
core
documents
to
finish
so
that
they
can
be
referenced,
but
there's
still
time
to
incorporate
feedback,
so
it
would
be
ever
so
helpful
and
drink
worthy.
If
you
were
to
do
that
and.
J
W
J
Drink
quality,
so
I
think
that
the
thing
is
maybe
I
can
try.
Maybe
there's
a
couple
other
people
who
know
HTTP
fairly
well
and
web
RTC
and
the
problems
went
wrong
with
it.
They
could
help
scope.
Some
of
this
into
that
that's
I,
mean
I.
Think
we
need
some
HTTP
expert.
We
look
so
here's
that
we
need
some
HTTP
clue
involved
with
the
people
who
are
sending
real-time
media
over
quick
right
like
we're
not
debating
that
sure.
J
W
It'll
be
great
if
you
looked
at
the
document
first
and
then
had
the
discussion,
because
the
h-2b
clue
doesn't
scale,
there
are
a
lot
more
people
trying
to
build
protocols
on
top
of
it
than
we
have
people
available
to
give
their
vendor
reviews
because
they
have
day
jobs
and
so
forth
and
so
on.
So
if
you
just
start
by
doing
that,
and
then
we
can
try
and
give
you
some
some
reasons,
fair
enough
I'll
do
that
okay,
I
won't
drink,
though.
O
Chris
went
I
generally
agree
with
the
discussion
going
on,
but
I
to
try
to
go
to
back
to
my
original
point,
I
think
there
has
to
be
some
explicit.
You
know
scope,
that's
decided
that
are
we
trying
to
solve?
You
know
some
interoperable
a
peer
to
peer,
signaling
or
multi-party
signaling,
or
are
we
trying
to
solve
like
things
like
how
contact
centers
interface
with
different
interconnection
points
and
all
this
other
stuff,
because
I
think
those
are
two
completely
different
problems.
O
P
Better
suggestions,
Bryan
Rosen
I
I,
keep
thinking
that
if
you
try
to
limit
the
scope,
somebody's
gonna
come
for
the
next
meeting
and
expand
the
scope
and
if,
unless
you,
unless
that
that
we're
really
are
better
off,
maybe
starting
with
a
subset,
in
other
words,
saying
well,
we're
not
gonna
boil
the
ocean
in
the
first
version
of
the
protocol.
But
if
our
intention
is
to
think
about
doing
this
over,
then
let's
design
it
that
way,
even
if
we're
starting
with
a
limited
scope
which
I
absolutely
admire
or
recommend
doing
start
with
limited
scope.
P
Just
don't
have
that
in
mind.
Don't
think
that
the
only
piece
we're
doing
is
that
whatever
you
start
with,
because
I
just
don't
think
that
that's
gonna
happen
I
think,
especially
if
it's
good,
because,
especially
if
it
succeeds
result,
we
will
have.
We
will
have
the
problems
that
we
created
and
said
right.
J
So
I
mean
III,
think
a
bunch
of
things
I
heard
today
really
rang
true
with
me
of
first
of
all,
I
totally
believe
that
this
group
of
people
will
inevitably
expand
this
to
fill
all
the
space.
You
know
all
the
type
of
problems
that
wants
to
obey
be
very
broad
scope,
right,
video
as
ekor
points
out
peer
to
peer,
so
it
seems
like
we
need
to
you
know
we
didn't
deal
with
a
lot
of
those
things
when
we
design
sip
from
day
one.
J
It
was
very
much
a
trapezoid
model
and
with
proxies,
which
then
didn't
exist,
I
mean
I.
Think
we
have
to
learn
from
that,
and
and
I
mean
like
what
Jonathan
said
about
video
can't
add
it
later.
We
can't
add
peer-to-peer
security
later
or
we
you
know
we're
going
to
have
to
hit
all
of
those
from
the
beginning.
Is
that,
like,
as
I
was
listening
to
everyone
talking
like
that
seems
inevitable
to
me?
J
We
could
we
could
discuss
for
a
long
time
how
big
that
ocean
is
and
how
much
we
wish
it
was
smaller,
but
in
the
end,
I
I
doubt
we're
willing
to
go
forward
unless
we
solve
some
of
those
problems
or
have
a
picture
of
how
they're
going
to
be
solved.
So
I
think
that's
the
direction
I'm
leaning
right
now
on
on
thinking
about
this,
which
does
not
make
it
a
mini
mini
anything.
So.
B
J
Mean
I
think
that
one
of
the
things
I
would
say,
particularly
in
this
negotiation
scope,
is
one
of
the
decisions
we
made
in
WebRTC,
which
extremely
limited
WebRTC
was
that
we
are
going
to
try
and
gateway
to
sip
from
WebRTC
without
processing
the
media
and
I.
Think
that
the
view
here
is
to
not
have
that
limitation.
Not
worry
about
the
past
not
heard
about
backwards.
J
J
A
A
The
scope
needs
to
be
constrained
yet
big,
the
the
the
almost
all
of
these
scope
questions
came
down
to.
You
had
to
be
good
if
he
can
constrain
this,
but
people
are
gonna,
add
on
to
it,
and
the
chairs
think
this
probably
Crosse
area
impact
here.
This
is
not
just
purely
art
because
we're
talking
about
transport
issues
and
all
these
things,
so
we're
feeling
like
what
we're
getting
for
hearing
trying
to
integrate
everything
we're
hearing
in
the
rooms
that
we're
talking
about
a
buff
and
yeah.
J
J
A
J
The
this
whole
discussion
is
expanded,
the
scope
greatly.
Then,
when
I
wrote
this
slide
right,
but
I
I
think
the
the
thing
that
we
need
to
think
about
is,
as
a
group
is,
how
do
we
move
things
along
quickly
versus
doing
them
away?
We've
always
done
them
and
that
doesn't
that
doesn't
remove
the
need
for
a
Boff
on
something.
That's
large,
okay,
I'm,
not
arguing
that
in
the
slice.
So.
A
E
This
is
Barry
liebe,
given
that
we
think
we
want
to
have
a
buff
on
this
in
Vancouver
that
restricts
when
we
could
get
something
formal,
but
we
can
certainly
set
up
a
mailing
list
and
have
people
continue
writing
documents
and
move
this
forward.
While
that
happens
and
I,
don't
think
we
should
wait
for.
X
E
U
Yeah
I
mean
I,
wouldn't
put
it
that
way,
arrogant,
but
I
think
you
know
you're,
surely
right
to
say
that
usually
right
to
say
that.
U
That
you
know
sometimes
discussions.
Everyone
knows
was
gonna
go
eight
months
from
now.
It
takes
forever
to
get
there,
but
I
guess
I,
don't
know
this
is
gonna,
get
where
this
is
gonna
go
and
so
I
think
you
know,
like
you
know.
Obviously,
you've
been
around
this
divorce.
U
Like
a
you
know,
you
know,
I
think
your
next
steps
are
like
sound
like
like
one
to
one
in
a
small
group,
socialize
these
ideas
and
try
to
like
Camille's
feedback
or
try
to
come
back
home
pros
all
that
you
think
addresses
like
most
the
people's
feedback
and
then
like
it,
and
we
can
crank
it
through
fast,
but
I
think
that
the
problem,
the
problem
here
probably
right
now-
is
all
the
process.
The
problem
right
now
is
consensus.
U
Now,
let's
say
you
can't
get
consensus
quickly,
but
a
problem
right
now
is
something
I
mean
the
problem.
The
reason
the
reason
people
were
saying
sure
of
off
is
not
just
because
a
lot
of
work,
but
it's
also
because
it's
like
they're
crazy,
like
a
fair
amount
of
like
non
total
agreement
out
what
want
to
be
done.
Okay,.
I
J
Think
we
could
be
seriously
ready
for
that
from
from
my
take,
but
I,
don't
think,
there's
anything
that
III,
don't
think.
There's
any
process
thing
that
eliminates
that,
but
I
do
not
think
the
advocates
of
this
would
would
have
something
that
answered
people's
questions
really
put
together
by
thinking.
I
Y
Elisa
Cooper.
We
could
update
that
RFC
about
how
to
have
a
successful
boss
didn't
plan
it
two
days
in
advance
as
one
of
the
recommendations
just
musing
about
this.
A
little
bit
I
think
the
tears
that
it
took
to
charter
RTC
web
is
small
compared
to
the
eight
years
it
took
to
complete
the
documents,
and
so
you
might
also
how
to
correct
for
that.
Given
that
it's
a
overlapping
set
of
interested
parties
in
an
effort
of
approximately
potentially
similar
size.
J
M
I
I
think
you,
you
actually
touched
on
a
way
to
make
this
faster
in
your
presentation
and
possibly
weren't,
holding
it
up
quite
high
enough
for
people
to
realize
it,
and
that
is
you're
you're.
Changing
the
interoperability
strategy.
Here
very
fundamentally,
by
saying
you
will
no
longer
care
to
make
it
simple
to
do.
Interoperation
with
legacy
devices
and
the
interoperability
strategy
that
was
taken
up
by
WebRTC
was
to
make
it
simple
to
do
inter
operation
with
legacy
devices.
By
presuming
that
the
gateways
themselves
were
very
simple
devices
and
not
responsible
for
the
media
and
I.
A
So
a
chair
comment
that
fell
at
fifteen
minutes.
We
said
we
had
is
almost
done.
I
think
what
we've
heard
still
is
we're
talking
about
a
buff.
We
want
to
find
ways
to
make
it
move
fast.
I
see
that
some
that
the
comment
about
having
a
buff
this
week
is
probably
not
realistic,
but
are
you
looking
at
site
meetings
this
week.
J
V
Moser
Danny,
since
you
presumably
looking
to
use
web
transports
and
they're
having
a
ball
later
this
week,
would
it
make
sense
to
try
to
have
a
barb
off
after
that,
because
I
mean
what
transports
doesn't
exist
for
itself?
It
exists
for
applications
on
top
of
it.
This
is
a
prime
application.
So,
if
that
work
moves
forward,
understanding
the
needs
of
a
real
application,
a
big
application,
you
know
we
could
move
faster
to
and
maybe
getting
all
the
right
things
that
we
need
out
of
what
transport
for
our
application,
yeah.
A
Though
I
think
the
resolution
we
have
here
is
that
the
proponents
and
the
area
directories
will
discuss
how
we
can
the
celery
with
the
Boff
the
idea
of
a
virtual
broth
with
mentioned
I,
don't
know
if
it's
doable,
but
it's
worth
discussing
the
I
noticed
you've
had
a
virtual
interim
on
February
on
your
slide.
You
know,
maybe
that
could
be
a
virtual
bath.
I,
don't
know
we
do
see
a
lot
of
interest
in
working
on
this
and
I
guess.
The
next
steps
is
like
I
said.
J
J
A
So
we're
now
moving
into
the
art
area.
Part
of
the
meeting
I
see
myth
mostly
the
same
people,
so
welcome
everyone
to
the
art
area.
Part
of
the
meeting.
The
first
item
we
have
is:
we've
got
some
buffs
out
there
and
some
other
groups
of
interest
I
think
we
have
a
slide.
Oh,
you
know
get
used
machinery
right.
A
Okay,
so
we
do
have
a
first,
a
couple
of
new
and/or
interesting
work
groups.
Obviously
all
the
working
groups
are
interesting,
but
these
are
the
ones
we
felt
like
calling
out.
In
particular,
we
like
to
call
out
Jenn
dispatch
and
then
also
mentioned
security
dispatch
partially
because
we're
so
proud
parents
of
the
new.
A
All
these
new
dispatch
working
groups,
but
also
I,
think
everyone's
interested
in
generating
and
there's
a
lot
of
overlap
between
things
that
are
going
on
in
this
room
and
things
that
go
in
security
dispatch
as
far
as
the
people
that
need
to
think
about
them.
So
we
would
in
we
would
hope,
as
many
art
participants
as
possible
can
attend
security,
dispatch
and
Ted.
M
Z
C
Z
Z
Working
group
deprive
that
rolled
out
among
other
specs
DNS
over
TLS
draft
and
then
two
years
ago,
or
so
we
started
the
DNS
over
HTTPS
working
group
with
the
idea
that
we
could
up
a
pop
up
working
group
get
in
get
out
and
we
would
solve
one
problem
and
be
done
turned
out
that
that
was
just
kind
of
turning
the
key
on
opening
a
whole
lot
of
other
things.
And
some
of
these
topics
that
DNS
over
HTTPS
has
brought
to
light
are
clearly
very
thorny
issues.
Z
But
there's
also
pretty
clear
to
a
number
of
us
that
there
are
some
technical
issues
that
we
can
adjust
address
in
a
relatively
policy
neutral
way,
and
so
ABCD
is
going
to
be
a
the
intent.
Is
that
it
is
a
working
group
forming
Boff,
where
we
can
hope
to
come
to
some
agreement
on
just
what
types
of
problems
we
can
solve
in
the
idea.
B
T
As
far
as
we
know,
we
don't
have
any
intent
to
figure
it
out
either,
and
so,
if
I
could
put
it
in
a
nutshell,
what
that's
about
is
I
think
I
think
of
it
as
the
next
step
beyond
WebSockets.
So
we're
going
to
start
off
by
introducing
some
of
the
work.
That's
been
done
on
quick
datagrams,
although
that
really
isn't
central
to
what
we're
doing
just
as
a
little
bit
of
background
and
then
talk
about
a
couple
of
proposals
for
taking
the
next
step
beyond
WebSockets
I.
Think
those
there's
something
called
a
web
transport
framework.
T
There's
two
proposals
on
HTTP
two,
you
know
and
hanison
connect
and
then
talk
also
a
little
bit
about
use
cases
and
I
think
Colin
covered
a
couple
in
there
that
are
some
of
the
things
people
are
been
thinking
of
doing
and
we've
got
90
minutes,
but
time
flies
when
you've
got
so
much
material,
so
David
and
I
still
have
to
work
through
how
much
we
can
do
and
how
much
should
be
allocated.
So
we
can
have
a
reasonable
amount
of
discussion
in
Q&A,
as
well
as
just
talking
to
you
with
slides
and.
AA
David's
gonna
see
a
quick
point
to
add,
so
this
is
work
in
partnership
with
the
w3c
that
is
so.
Websocket
is
an
API
available
to
the
web,
WC
stuff
and
they're
interested
in
leveraging
new
transfer
protocols,
most
notably
quick
and
levered,
offering
those
rich
features
to
the
web.
So
we've
we
were
there
particular
at
tea
back
a
few
months
ago
and
there
was
interest
there.
So
the
idea
here
is:
let's
see
what
we
can
build
in
term
of
IT
protocols
to
support
that
work.
B
Okay
and
also
on
Wednesday,
we
have
the
W
pack
Webb
packaging
Boff,
which
also
has
nothing
to
do
with
DNS
or
not
much.
In
any
event,
this
is
the
sort
of
logical
progression
of
the
work
that
Jeffrey
askin
has
presented,
I
think
in
dispatch
in
the
past,
involving
HTTP
and
essentially
offline
signed
exchanges
and
what
that
means
when
separated
from
sort
of
a
transport
context
of
the
security
and
distribution
considerations
of
that,
and
so
that's
what
we
talking
about
that
is
a
potentially
working
group
performing
Boff
Wednesday
afternoon.
B
A
And
then
we
have
a
few
moths
that
are
outside
of
the
art
area,
but
may
still
be
of
interest
for
people
if
anyone
is
in
the
room
that
isn't
a
position
and
would
like
to
plug
you
and
they're
welcome
to
I'm,
assuming
that's
not
going
to
be
true
for
mathematical
magic.
That
baath
is
going
on
now,
but
as
far
as
the
other
three
is
anyone
here,
that's
a
chair
or
is
otherwise
interested.
Who
can
not
speak
to
them?
I.
AB
AC
There's
already
some
stuff
that
exists,
I
can
remember
to
put
on
the
slides
here
in
this
space.
Apple
have
their
own
thing
except
or
push
which
exists
in
IMAP
and
exists
in
Kelvin
card
eV,
and
their
devices
will
connect
to
a
server
that
supports
it,
and
it
says
please
push
me
updates
through
the
Apple
notification
service
back
to
the
device,
and
it
will
know
that
something's
changed
and
in
close
to
real
time,
it
gets
updates
for
other
first
party
clients
like
the
Gmail
client
with
Gmail.
AC
Again,
they
will
get
pushes
straightaway
through
their
protocol
because
they
control
both
ends
and
they
can
put
something
in
between
back
there
and
it
all
works
nicely
for
third
party
clients
they're
pretty
much
out
of
luck,
they're
stuck
poling
or
they're
stuck
implementing
every
single
service
providers,
custom
protocol
just
for
them.
So
there
are
a
couple
of
isn't
this
great
a
couple
of
existing
drafts
for
this
for
caldera
and
cardova,
there's
been
a
proposed
draft
to
add
push
just
to
there
and
for
IMAP.
AC
There's
now
proposed
draft
to
add
a
push
mechanism
there
as
well
from
the
dovecot
people.
All
of
these
it
would
be
good
to
have
a
standard
way
of
doing
it,
so
everyone's
not
implementing
their
own
thing.
J
map
has
implemented
its
own
thing
because
there
was
nothing
else,
but
it
would
be
good
to
make
sure
that
anything
else
that
comes
along
the
lines
with
that.
So
I
guess.
My
question
for
this
group
is:
where
should
this
work
happen?
Well,
first
of
all,
should
it
happen
at
the
ITF?
AC
That,
yes,
it
is
okay.
Roughly
there
are
currently
two
of
those
yeah,
but
what
doesn't
exist
is
a
standard
way
to
tell
the
service
provider
to
push
through
those
channels
or
more
specifically,
there's
there's
two
there's
Google's
way
and
Apple's
way,
yeah
and
there
would
be
nice
to
have
one
way,
but
the
average
protocol
doesn't
have
that
built
in
you
can't
just
go
to
a
random
car,
dev
server
and
say.
Please
push
me
updates
to
my
address
book
via
my
protocol,
that
I
know
how
to
recognize
through
the
Google
push.
J
Channel
right
so
I
mean
I,
think
the
question
I'd
be
looking
for.
I
mean
I
love.
This
I
argued
for
something
like
this
many
years
ago,
but
it's
it
doesn't
matter
unless
both
those
two
push
notifications,
that
are
everything
today
are
willing
to
implement
that
API
unless
they're
willing
to
do
that.
I
don't
like
that
seems
to
be
the
you
need.
AC
J
Classification,
I,
don't
yeah
III,
guess
I
think
this
is
overly
simplifying.
What
you're,
like
the
picture
you
said
of
like
there's,
somebody
like
Twilio,
who
provides
a
common
API
that
then
pushes
it
to
the
Android
and
Apple
back-end.
I
can
imagine
that
working
but
I
think
you
need
to
describe
solutely.
AD
AD
I
yeah
just
clarifying
the
scope
of
this
a
little
bit.
This
is
about.
If
you
have
a
third-party
client,
that's
going
to
talk
to
mail
contacts,
calendar
or
whatever
server,
which
is
not
owned
by
the
same
company
you
want.
It
needs
some
way
of
saying:
hey
I,
have
this
push
channel
that
I
can
receive
stuff
from
and
so
that
app
registers?
Yes,
a
certificate
with
Apple
or
Google,
so
it
can
receive
pushes,
but
it
needs
to
have
some
way
of
tones
giving
the
service
provider
to
push
information
in
a
way.
AD
That's
gonna
end
up
routing
back
to
that
fight,
and
that
might
so.
We
have
our
C
80
30,
which
is
kind
of
how
all
this
can
all
work
together.
You
know
standardized
way,
but
what
we
need
is
a
standardized
way
for
the
client
to
set
up
that
whole
channel
with
the
service
provider.
But
that's
my
attempt
clarifying
that
which
may
not
be
that
clear,
but.
AE
Staff-
gentle
sorry,
I
Neal.
You
might
have
just
answered
my
question
but
I'm
trying
to
be
clear
on
whether
as
a
point
of
clarification
is
this
third-party
applications,
so
the
Twilio
app
on
my
phone
or
is
this
specifically
for
things
like
calendaring,
an
email
where
I
don't
necessarily
install
an
app
for
my
particular
service
provider
on
my
phone?
AC
You
install
cool
calendars
on
your
phone
and
cool
calendars,
connect
to
your
CalDAV
server
and
says
hi
I'm,
an
app
that's
on
a
Android
phone.
So
please
push
to
the
Google
notification
service
with
my
apps
registered
ID
against
Google.
To
tell
me
when
there
are
changes
to
my
account
on
your
service.
Great.
Thank
you.
AF
D
E
AC
Q
AG
C
AG
One
so
again
we're
we're
exactly
this
happens.
I
I,
don't
know
what
one
thing
to
consider,
though,
is
that
often,
with
these
at
least
my
experience
with
both
both
push
services
have
been
the
major
push
services
have
been.
There
needs
to
be
an
existing
relationship,
not
just
between
the
application
and
the
device
it's
on,
but
the
service
that's
providing
it
and
that
push
service
like
there.
There's
there's
a
lot
going
on
here,
yeah
that
that
that
really
needs
to
be
part
of
this
consideration.
AC
I
mean
there
certainly
needs
to
be
some
way
to
deal
with
the
abuse
can
generations,
which
is
why
everyone
requires
the
registration.
But
we
want
to
wind
up
in
a
situation
where
you
can
take
arbitrary
third-party
client,
a
against
arbitrary
server
B,
and
they
don't
have
to
have
a
pre-existing
into
EM
relationship
in
order
to
have
any
push
at
all.
AG
Sure,
like
like
I,
mean
a
lot
of
what
I've
seen
has
been
the
concern
about.
You
know
about
spam,
not
just
from
a
client
receiving
too
much
butter,
but
a
service
receiving
too
many
bogus
requests.
Yeah
and
that's
that's
where,
like
cool
the
cool
app
or
my
calendaring
service,
would
have
to
have
a
relationship
with
Google
and
Apple
in.
AC
Order
to
push
yeah
things
I
expect
on
this
picture
here
that
you're
cool
client
would
have
a
cool
calendar.
That
client
would
have
the
user
device
registration
against
a
cloud
service,
so
it'd
be
registered
with
if
it's
an
Android
app
would
be
registered
with
Google
and
it
would
have
its
application
ID
and
each
instance
of
it
would
have
a
user
ID
that
was
registered
with
Google.
That
said,
pushes
for
my
device
use
this
key
to
here,
then
there
needs
to
be
some
way
to
register
with
arbitrary
CalDAV
server.
Albert
Ricardo
server.
AC
AG
O
Chris,
when
I
was
gonna,
make
a
similar
comment,
I
I
think
I'm
more
familiar
with
Apple
than
Google's
notification
service,
but
I
think
they've
made
that
extremely
restrictive.
Now,
where
you
know
you
can't
even
share,
because
we
operate
a
a
service
on
my
team
that
does
some
of
these
similar
things
and
you
know,
we've
had
to
go
around
hoops
even
just
to
pass
notifications
from
different
applications
through
the
same
channel,
so
yeah
I.
If,
if
you
were
already.
AH
AC
AC
Certain
if
you
draw
a
four
party
version
of
this
way,
you
have
two
things
in
the
cloud,
one
of
which
is
cool
calendar
services,
endpoint
that
you
push
to
that
their
device
is
registered
against,
and
then
it
has
its
via
Apple
or
via
google
channel
kind
of
embedded
between
its
cloud
endpoint
and
its
device.
And
so
you
tell
the
CalDAV
server
to
push
to
cool
calendar
services.
Cloud
endpoint
that
then,
whatever
path
that
follows
gets
through
to
the
device
to
tell
the
device.
Here's
the
change,
but.
AD
This
is
Neil
Jenkins,
again
yeah.
The
the
way
you
make
this
work
for
now
is
that
the
app
on
the
phone
or
wherever
has
to
also
have
its
own
server
component
and
that's
what
the
service
provider
actually
talks
to
and
then
that
server
component
obviously
is
registered
same
way
as
the
client
is
with
the
push
service
it
wants
to
use
and
has
all
this
difficut
since
to
actually
get
the
push
to
the
user's
device
potentially
in
the
future.
AD
Apple
or
Google
may
support
RFC
80
30
on
its
own,
so
you
don't
need
something
in
between,
but
in
the
meantime
that
that's
how
you
would
make
it
work.
That's
that's!
It's
still
a
useful
thing
of
yes,
the
of
the
having
stand
way
for
the
device
to
register
that
it
wants
to
receive
these
on
its
audit
server
from
from
the
service
provider.
That
actually
has
the
data.
AC
Alright,
so
I
guess
next
step
Alexi
is
to
talk
to
you
once
you've
had
a
chance
to
to
think
about
whether
extras
the
right
home
for
this
area
of
work
or
to
bring
it
for
a
ball
or
something
else.
Later,
though,
this
is,
this
is
not
actually
my
work.
It's
work
that
I
see
out
there
in
the
world
happening
in
a
couple
of
different
places.
That
I
think
should
be
coming
to
the
ITF.
AC
A
Has
been
Campbell
from
the
chair
as
far
as
these
work
from
other
places
that
need
to
come
to
that
ETF.
Do
you
think
these
people
or
people
that
would
participate
in
the
process
and
the
idea
yes
and
then
I'll,
go
further
to
say
the
conversations
get
a
little
bit
dispatcher
here,
but
that's
I,
don't
think.
A
That's
a
problem,
but
I
think
one
of
the
big
things
to
find
here,
since
there
are
several
different
pieces
that
work
going
on
is
you
know
who's
interested
in
and
paying
and
working
on
this
sort
of
thing,
and
how
can
these
work
efforts
be
combined
or
at
least
coordinated,
and
that's
be
a
good
discussion
to
have?
What
are
your
next
steps
on
that
discussion?
Not
counting
just
we're
actually
talking
about
where
it
would
stay
or
are
you
thinking
about
other
site
meetings
or
yeah.
AC
A
AC
Z
All
right,
so
most
of
this
conversation
is
going
to
be
happening
at
sec
dispatch
tomorrow
afternoon,
but
because
the
whole
idea
of
signing
an
HTTP
request
message
is
very
much
right
at
that
border
of
the
sec
area
and
the
art
area.
I
wanted
to
get
people
in
this
room's
attention,
so
the
TLDR
version
is
that
people
want
to
sign
HTTP,
request
messages,
whether
or
not
you
agree
with
that
as
a
goal,
people
are
doing
it
for
lots
of
different
reasons.
Z
Z
Jose
doesn't
solve
everything,
but
the
important
thing
here
for
this
group
is
that
people
are
actually
doing
this
out
in
the
wild.
There
are
at
least
five
major
versions
of
this
I
invented
at
least
two
of
these
myself
and
I've
implemented
almost
all
of
these
as
well,
and
they
all
solve
different
bits
and
pieces
of
the
problem.
Z
The
thing
is
even
as
an
as
an
implementer
and
as
a
draft
editor
I
don't
know
if
there
is
a
universal
solution
or
if
there
should
be
a
universal
solution,
but
the
fact
that
people
are
building
these
things
and
using
them
today
for
lots
of
different
but
related
use.
Cases
is
telling
me
that
it's
really
starting
to
get
to
the
time
where
we
need
to
look
at
this
as
as
a
holistic
solution,
space
and
figure
out
where
these
things
are
going
so
gonna
be
talking
more
about
that
at
sec
dispatch.
Z
Z
So
the
basically
I
don't
know
where
this
needs
to
land
but
I'm,
getting
a
stronger,
installer,
stronger
feeling
that
this
does
need
to
land
somewhere
at
some
point,
hopefully
in
the
near
future.
So
any
thoughts
or
questions
and
like
I,
said
we're.
Gonna
have
we're
gonna
have
a
chance
to
get
into
deeper
discussion
on
this
during
SEC
dispatch,
but
I
do
want
to
respect
people's
time
here
and
let
you
guys
know
this
exists.
Yes,
how.
M
It's
a
dirty:
they
are
completely
and
utterly
distinct.
Yes,
and
so
the
there
was
a
discussion
at
some
point
earlier
on
the
W
PAC
list
about
whether
they
ought
to
be
yoked
together
and
the
the
rending
of
teeth
and
gnashing
of
clothes
or
strike
that
reverse
it
was
quite
high.
This
is
already
difficult
enough
and
the
set
of
systems
you
might
want
or
responses
and
for
requests.
AD
AI
Z
Z
I'm
not
sure
yet
so
so
I
think
maybe
there's
a
grand,
unified,
HTTP
signing
thing
that
needs
to
exist.
I,
don't
know
so
cabbage.
Signature
draft
is
probably
the
most
implemented
one
out
there,
but
that
also
has
some
pretty
severe
limitations
into
in
what
it
can
express
and
what
it
can
do.
So,
whether
we
start
there
and
build
on
the
stuff
that
depop
add
I
I
don't
actually
know.
Z
AB
AI
Z
W
Mark
Nottingham,
so
just
to
give
some
flavor
and
other
discussions
motor
insect
dispatch.
We've
had
this
on
kind
of
the
radar
in
the
HTV
working
group
for
at
least
a
couple
of
years.
We
have
draft
cabbage
on
our
list
of
documents
to
watch.
Okay
and
I
think
we
haven't
moved
on
it
yet
because
of
the
issues
you
you've
raised
of
there's
a
lot
out
there.
It's
not
really
clear
what
the
right
solution
is
here.
My
heart
are
hired
or
bit
concerns
with
moving
forward.
W
W
W
Z
W
That's
really
I
think
that's!
The
interesting
information
here
is:
is
that
we've
been
putting
it
off
for
so
long
because
getting
engagement
with
the
disparate
communities
has
been
hard
and
there's
been
a
lot
of
churn
yeah
and
and
if
we
can
get
some
consolidation,
where
we
can.
Okay,
let's
go
in
this
direction
and
solve
this
percentage
of
the
use
cases.
It's
it's.
Maybe
it's
worth
trying
so
absolutely.
W
Z
S
S
Just
want
to
mention
that
the
the
art
part
of
the
problem
really
was
understanding
well,
what
is
a
request
in
the
first
place
mmm-hmm?
So
how
much
context
do
you
actually
have
together
before
you
can
design
that
before
you,
okay,
not
Santa,
Kate
it?
What
is
the
freshness
concept
you're,
using
lots
of
things
going
on
that
really
application
related
to
the
protocol
that
you're
trying
to
support
right.
Z
V
Z
Z
C
Z
Z
To
manage
the
HTTP,
yeah
and
perhaps
and
deprecating
HTTP
and
doing
something
sensible
might
also
be
a
way
to
approach.
The
problem.
I
want
to
take
that
last
bit,
probably
off
the
table
for
right
now
and
just
to
be
cognizant
of
time
constraints
and
stuff
like
that
for
a
bit
of
context
that
I
breezed
through.
We
are
specifically
looking
at
detached
style,
signature
systems
here
and
not
encapsulated
signature
systems
here,
so
we
actually
want
to
use
HTTP
as
HTTP
without
copying
all
the
stuff
into
some
sub
object
and
without
hiding
all
of
that
stuff.
Z
A
We
encourage
everyone
who
commented
here
go
make
the
same
comment
affect
dispatch.
I.
Think,
though,
if
the
minutes
capture,
at
least
this
discussion,
suggested
that
the
art
related
issues
is
this,
maybe
that's
some
of
the
harder
ones
and
that
HTTP
this
might
be
a
good
place
that
we
worked
on.
But
this
is
all
subject
to
further
discussion.
It's
gonna
happen
inside
dispatch.
A
B
J
B
B
Look
at
that
dispatch
work.
We
have
dispatched
to
a
site
meeting.
That's
already
been
scheduled.
I
want
to
thank
everyone
for
their
consideration
today
and
also
remind
you
that,
just
by
just
not
just
an
IETF
week
phenomenon.
So
if
we
read
the
mailing
list
and
participate
on
the
mailing
list
and
bring
your
work
there,
it's
even
plausible
to
dispatch
things
between
meetings,
which
I
think
is
a
really
exciting
possibility.
So
keep
that
in
mind
is
anything
else
not.