►
From YouTube: IETF93-WEBPUSH-20150723-1740
Description
WEBPUSH meeting session at IETF93
2015/07/23 1740
A
If
I
receive
the
push
right,
that
shouldn't
be
the
job
of
the
push
service
right,
that's
my
application
level.
I'm
telling
hey
I
received
that
we've
got
a
lot
to
it.
There
are
other
cases
in
which,
and
in
it's
great
for
battery
life,
another
and
saving
network,
in
which
the
pre-service
can
take
this
job.
It's
like
yeah,
we
know,
will
we
deliver
this
and
I'll?
A
Let
you
know
right
when
you
go
to
TTL
the
the
time
to
leave,
it
will
be
very
hard
to
implement
something
that
says:
hey
just
expired,
so
I
let
you
know
right
up.
You
can
safely
assume
that,
based
on
your
TTL
that
never
got
pushed
right
and
then
they
will,
they
will
shoot,
always
be
a
maximum
cap
of
time
to
leave
right.
A
So,
therefore,
you
can
always
assume
the
message
never
got
delivered
and
the
reason
for
a
maximum
cap
is
that
it
often
happens
that
people
with
multiple
devices
with
them
in
the
drawer
for
years
by
and
there
is
some
sort
of
garbage
collection
that
needs
to
happen.
So
we
are
making
an
example
in
our
system.
We
decided
30
days
was
enough
for
you
to
not
choose
the
advice
anymore,
and
so
that
will
be
your
max
detail.
In
that
case,
you
can
always
assume
so
no.
B
Mozilla
looking
at
this
at
implementing
a
maximum
TTL
as
well,
and
so
the
protocol
actually
supports
this-
the
I
think
that
a
fault
CTL
is
zero.
So
if
you
don't
specify
anything
in
a
request
from
the
application,
so,
but
that's
what
you
get,
but
if
you
specify
that
I
would
like
a
TTL
of
seven
years.
B
Clearly
the
service
doesn't
want
to
support
storage
of
this
useless
information
for
that
period
of
time
it
actually
responds
in
is
its
acknowledgment
saying
no.
This
is
the
real
TTL
and
is
required
to
make
that
strictly
less
than
or
equal
to
the
value
that
was
requested,
and
so,
if
the
application
see
something
that
it
doesn't
like
because
it
gets
TTL
equals
zero
on
the
way
back
out
again
well
suck
it
up
I,
it
really
has
no
recourse
at
that
point.
That's
what
that's
really!
D
C
E
B
B
You
you
may
have
different
different
math
on
the
on
the
costs
of
operating
the
service
and
all
sorts
of
other
things
that
come
into
play.
There
I
think
on
those
sources,
I'm
scales-
maybe
it's
maybe
it's
not
a
concern.
A
member
can
be
a
little
bit
looser
on
the
on
the
requirements
as
with
it,
I
guess.
The
point.
A
G
A
If
we
accept
the
message
and
we
can't
deliver
for
whatever
it
is-
and
it's
pires
like
there
should
be
no
next,
so
two
three
slides
back
when
you
have
like
we
try
to
deliver
the
liver,
deliver,
there's
something
wrong
with
a
next
this
one
other
step
with
a
user
agent
I.
I
do
not
think
we
should
have
a
knack,
but
you
don't
think
this.
A
B
B
H
I
do
not
want
the
application
servers
who
to
just
send
that
again.
It's
not
expired
because
the
user
age
never
came
online.
It's
something
that
is
really
nice
for
the
application
server
to
know
that
that
message
is
not
working
and
it's
consuming
a
lot
of
resources
for
no
reason,
and
that's
very
different
from
the
user,
that
the
smartphone
was
in
a
drawer
and.
B
That
to
be
clear,
this
isn't
the
only
reason
why
you
might
send
something
like
this.
The
only
reason
you
the
the
description
of
this
was
the
push
service
gives
up
whatever
reason.
Now
it
could
be
that
it's
overloaded
and
has
to
shed
some
state
or
it
was
deemed
to
be
poisonous
or
I,
don't
know
what
I'd.
A
Like
to
reply
amenia,
what
is
the
use
case
right,
sir?
So
if
the
user
region
can't
accept
the
message,
it
is
overloaded
sure.
Well,
you
should
at
a
later
right.
It's
not
just
this
message
why
what
the
application
server
can
do
right
if
you're,
overloaded
and
push
service
to
say,
hey,
500,
wait
right,
so
I,
don't
think
user
agent
and
say
I'm
overloaded
for
this
one
messaged,
you
don't
send
it
again.
Second,.
B
A
A
That
would
be
the
right
so
why
they
should
why
the
push
service
is
the
one
saying
like
hey
you
all
right
into
the
content
for
your
own
app
that
we
acted
like
this.
You
know
we
were
acting
an
application
level
protocol,
which
is
bad.
It
makes
incense
I
really
don't
see
any
use
case
in
which
the
user
agent
agent,
which
is
part
of
service,
tell
the
push
service.
This
is
bad
as
the
only
case
for
this
message
for
the
application
server.
When
everything
else
is
fine.
I.
H
H
It's
true
that
it's
like
shitty
code,
like
you
put
it
for
from
from
the
application,
server
and
the
end
the
application,
but
but
that
ends
up
generating
more
traffic
and
and
and
including
in
the
Indian
more
problems,
so
people
I'm,
fortunately,
to
write
shitty
code
and
we're
trying
to
to
avoid
to
put
them
in
a
position
to
avoid
consuming
more
resources
than
necessary
for
the.
For
that
reason,
we
actually
want
to
provide
that
service
if
you're
a
how
how
somebody
writes
a
reliable
message
that
delivery
from
the
application
server
to
their
application.
H
I
F
Up
taking
too
long
robert
sparks
so
and
you
in
particular
francisco's,
so
I'm
replying
to
application
server
sends
a
push.
The
push
service
push
service
sends
a
push
to
the
user
agent
user
racing
crashes
crashes
in
a
way
that
the
push
service
can
tell
holy
crap.
I
just
crashed
that
user
agent.
I'm
not
going
to
send
that
message
to
it
again.
It'd
be
nice
to
tell
the
application
server.
Don't
tell
me
to
send
that
message
again
and
that's
really
what
you're
talking
about.
B
A
A
F
Next
and
rollin,
the
faculty
user
agent
crashes
doesn't
necessarily
mean
that
that
message
is
bad.
It
could
be.
You
send
to
any
message
and
will
crash,
because
you
can
allocate
memory
or
the
some
other
basic
problem.
That
means
that
any
message
you
sent
it
is
or
any
message
of
that
size
that
you
sent
it
is
going
to
be
a
problem,
so
I
think
there's
lots
of
reasons
why
user
agents
might
not
respond
to
a
message.
K
K
I
would
also
agree
that
there's
cases
where
you
don't
need
that
that
acknowledgement-
and
maybe
maybe
there's
a
negative
acknowledgement
and
maybe
there's
a
way
to
convey
that
the
subscription
level
I
don't
know
but
I-
think
I
think
there
are
third
use
cases
where
you
definitely
want
as
an
application
developer
running
an
application
server
not
to
do
too
much
there,
because
you're
delegated
up
to
the
purser.
So.
B
B
Duggal
are
going
to
say
well
if
I
crash
the
phone
and
I
do
it
again
and
I'll
do
it
again
for
the
next
four
weeks,
that's
cool,
not
my
problem,
I'm
not
going
to
give
up,
and
so
they
never
have
to
send
a
knack
in
that
situation.
If
you
never
actually
give
up
as
a
result
of
not
being
able
to
deliver
a
message,
then
you
know
actually
have
to
worry
about
sending
a
knack
and
you
can
be
compliant
with
the
protocol,
but.
H
This
is
earlier
again
from
Microsoft
in
general.
I
think
that
the
conditions
which
this
Mac
can
be
generated
can
be
more
multiple
than
more
than
we
have.
We
have
some
and
it
one
way
is
that
it
would
be,
could
make
it
generic
meaning
that
you
could
have
like
some
some
effectively
some
equipped
with
codes
and
only
prescribe
some
of
those
but
like
you're,
saying
Google
will
implement
some
and
will
will
permit
others
what
is
in
general.
H
Sometimes
before
four
weeks
have
passed
or
things
like
daddy.
But
you
want
to
know
if
you're
effectively
like
crippling
your
devices
with
specific
messages,
and
you
want
to
know
exactly
what
device,
because
that
could
change,
depending
on
many
things
and
one
to
correlate
that
information
with
the
specific
firmware
version
that
you
have
on
that
device
on
and
so
forth.
C
B
One
of
the
pieces
of
advice
that
we
can
give
here
is
their
applications.
Application
servers
should
not
attempt
to
resend
the
exact
same
message
to
the
so
the
device.
No
one
of
the
one
of
the
examples
of
earlier
gave
me
when
we
were
talking
about
this
and
I
took
a
little
while
to
be
convinced
that
this
was
even
necessary.
Was
that
you
send
a
particular
message,
saying
here's
a
state
update
or
something
like
that,
and
it
caused
an
explosion
of
some
form
or
other.
B
You
don't
know
exactly
what
happened,
although
you
can
actually
provide
some
information
from
you
from
the
push
service
in
the
body
of
the
response.
It's
not
machine
processable
necessarily,
but
it
could
be
read
by
human
and
passed
out
if
necessary,
but
in
that
situation
they
would
receive
the
act
in
the
neck.
Go
damn
I
can't
do
an
incremental
state
update
on
this
advice.
B
I'm
gonna
send
a
minimal
message
down
to
the
device
that
I
know
it's
sort
of
failsafe
code
that
says
you're
out
of
sync
restart
and
then
that
would
trigger
a
different
set
of
logic,
and
maybe
it
wouldn't
crash
that
time
and
then
so.
You
do
actually
have
options
there.
I
know
you
can
just
flag
an
easy
that
in
your
database
in
and
have
your
ops.
B
J
Joe
Hildebrand
I
wonder
if,
if
the
goal
of
the
working
group
is
clear
enough
here
in
terms
of
the
level
of
reliability,
we're
trying
to
achieve
from
every
like
it's
controlling
it
to
what
have
we
signed
up
for
question
and
I'm
carefully
saying
this
from
the
floor
not
from
from
from
the
chair
spot
because
I
don't
want
to
you
know:
I
just
want
to
make
sure
that
we're
all
on
the
same
page
with
that
yeah.
So.
J
How
great,
but
I
think
this
this
particular
question
of
what
are
we
trying
to
solve
and
in
this,
like
the
specific
edge
of
it,
is
likely
to
come
up
eight
more
times.
So,
let's
this,
if
we
can't
get
some
sort
of
consensus
on
this
one
as
sort
of
the
canary
in
the
coal
mine
we're
going
to
keep
having
the
same
conversation
over
and
over
again,
so
I'm
wondering
if
there's
sort
of
any
flexibility
on
either
the
sides
to
see
you
know,
hey
can
I
see
the
world
the
other
way.
J
What
would
that
mean
for
me
that
kind
of
thing
like
could
you
live
with?
Is
this
like?
Is
this
the
like?
The
whole
thing
is
not
worth
doing
if
you
can't
have
this
particular
app
and
they
ate
more
that
we're
going
to
find
later,
or
is
this
not
worth
doing
if
I
have
to
send
all
these
acts
and
the
eight
more
later
so.
A
Some
malignant
from
the
last
word
of
Elliott,
saying
IOT
I,
think
I
got
his
point
now.
If
we
assume
the
user
agent,
it's
not
push
his
code.
What
is
developer
of
application
server
now,
then
that
makes
sense,
because
they
have
no
idea
that
they
crashed
because
of
the
neck
and
I
can't
own
server.
Well,
that's
a
different
yusuke's
up
to
as.
A
A
But
but
we
need,
the
protocol
needs
to
be
accommodating
for
the
two
very
different
use
cases
right
it.
There
are
two
worlds
here,
one
world
in
which
that
is
central
intelligence
on
the
device
on
the
end
device
that
dispatch.
The
message
is:
this
is
the
case
of
GCM
today
and
there's
another
one
which
is
more
likely
an
IOT
use
case
we're.
Actually,
you
might
have
multiple
connections
to
the
push
service
from
the
same
device,
because
the
apps
icon
their
own.
We
need
to
realize
in
one
case-
and
that
makes
sense
in
the
other
doesn't
say.
J
B
So
I
think
we're
kind
of
here
and
then
some
details
to
work
through
and
we
have
to
talk
through
the
TTL
0
thing
in
user
mode,
more
detail
in
and
this
is
actually
kind
of
in
the
draft,
but
it
needs
a
lot
more
meat
around
it.
So
what
we'll
do
is
we'll
get
right
on
that
and
send
some
text
to
list,
and
so
so
you
know.
F
B
F
B
It
turns
out
that
you
have
this
symmetry
that
goes
on,
and
then
you
end
up
with
this
wonderful
infinite,
recursion
problem
to
about
three
iterations
or
something
like
that.
I
I
have
a
position
on
this
one.
Let's
not
worry
about
this.
For
now
there
are
things
we
can
do
about
this
potentially
in
the
future.
B
K
B
J
B
F
B
B
With
it,
yeah
there's
a
handful
of
slides
of
nothing
quick,
more
right
through
this,
so
there's
there's
a
number
of
questions.
I
want
answered
out
of
this.
The
high-order
bit
is
are
we?
Are
we
interested
in
adopting
the
proposal
that
I
have
put
forth
for
crypto
and
then
there's
some
questions?
The
flow
on
format,
so
no
I
have
the
means.
Here
we
go
again.
Look
at
that.
B
So
let
me
first
summarize
what
we
have
so
based
on
some
review
and
some
feedback
from
a
bunch
of
people.
I
have
updated
the
encryption
draft
to
cover
actually
tracks
TLS
13,
so
to
a
large
extent,
we
actually
have
a
hold
of
uncertainty
about
the
record.
My
own
tell
us
13,
so
the
the
record
structure
in
the
in
the
base
encryption
draft
that
I've
talked
about
in
HTTP,
has
been
updated
to
match.
Tell
us
13
and
there
were
some
people
concerned
about
the
original
structure.
B
Funnily,
only
enough
there
were
some
parallel
concerns
raised
on
this,
and
concerns
raised
in
TLS
13
that
were
both
the
dressed
in
the
same
fashion
for
push
I
have
simplified
the
record
structure,
and
there
were
some
concerns
from
david
benjamin
at
Google,
who
was
looking
at
analyzing.
This
whole
whole
thing
and
we
had
an
interesting
discussion
on
this
point.
B
He
didn't
like
the
idea
that
someone
generating
a
push
message
might
be
able
to
split
the
push
message
up
into
multiple
records,
given
that
it's
only
4k,
it
really
doesn't
make
to
run
the
a
EAD
multiple
times
and
then
have
to
worry
about
truncation
and
all
sorts
of
other
funny
things.
So
I
have
required
that
someone's
sending
a
push
message,
send
a
single
record
and
that
they
don't
run
the
trap
or
truncation.
So
they
set
a
very
large
value
for
the
record
size.
B
B
B
So
if
I
going
to
519
appears
to
be
better
because
the
CFR
G
Tolleson
I
mean
why
would
they
do
it?
If
it
wasn't
so
we
have
a
choice
and
that
choice
is
the
difference
of
one
way
or
another,
and
I've
asked
Mike
and
I've
asked
Peter
and
I
have
asked
Matt
I
think
as
well
to
offer
their
opinions
on
the
subject,
and
it
I
think
there
might
have
been
a
few
other
locusts
around.
You
actually
know
what
they're
talking
about
to.
G
I
I
The
primary
reason
that
we
chose
that
we
chose
for
this
from
google
chrome's
perspective.
This
is
the
web
boost
protocol
and
my
main
interest
is
chrome-
is
a
browser
and
delivering
this
as
a
service
to
web
developers.
It's
that
the
vast
majority
of
websites,
as
opposed
to
applications-,
to
a
phone
or
to
an
operating
system,
use
interpreted
languages
on
the
server
side,
such
as
PHP
and
Python,
which
which
don't
have
good
availability
of
any
of
these
features
all
together
to
illustrate,
is,
for
example,
in
PHP,
which
is
a
very
popular
languages,
language
for
websites.
I
It
it
advertises
availability
of
ASTC
em,
but
it
actually
returns
a
sgtm
without
the
authentication
tax.
So
it's
just
completely
pointless
from
the
point
of
reduction
in
these
languages.
There
is
little
like
it's
going
to
be
hard.
It's
going
to
be
hard
for
people
working
in
these
languages
to
adopt
the
encryption
draft
all
together,
and
we
don't
think
that
that
we
need
to
make
consensuses
or
that
we
need
to
choose
a
curve
like
be
256
with
better
deployment.
B
I
So
at
Google
we
we
actually
implemented
the
curve,
255
19
donna
implementation,
and
it
is
available
as
extensions
for
both
the
pm
python,
together
with
implementations
in
many
other
languages,
as
opposed
to
a
HTC
em.
That's
a
much
harder
problem,
because
that
there
are
that's
much
harder
to
implement.
That's
timing
sensitive
and
we
don't
want
developers
to
create
their
own
implementation
there,
whereas
for
curve,
255
19
is
much
easier
to
implement
a
correct
implementation,
different
from
be
256.
Given
that
it's
a
simpler
curve.
G
Matt
Miller,
so
least
in
my
experience
of
working
with
these
things,
I
I've
usually
found
p
256
available
because
it's
an
open,
SSL
and
it's
in
a
couple
other
core
crypto
libraries
that
get
passed
around
a
lot
that,
at
least
for
the
things
I
deal
with
most
I
mean
most.
My
stuff
is
a
node
and
Python.
Both
of
those
there
are
pretty
decent
mappings
into
from
openness
on
to
them.
The.
G
It
at
least
in
the
latest
note
it's
not
horrible.
You
get
the
F
indication
telling,
but
there's
also
this
incredibly
large
base
of
java
applications
java
servers
where
p
256
is
there
in
various
flavors
already
so,
at
least
from
my
perspective,
as
somebody
that's
written
a
lot
of
server
code,
that's
got
to
get
pushed
around
256.
Is
there
225,
519,
isn't
quite
I.
J
Think
Matt
actually
answered
the
question.
I
was
going
to
ask
you
Mike,
so
that
was
was
if
I
was
going
to
have
to
write
new
code
anyway,
for
either
of
these,
then,
should
we
use
the
better
one,
and
the
answer
is
because
it's
an
open,
SSL
and
in
the
Java
I
got
I
understand
it's
unfortunate,
but
at
least
I
understand
and.
G
I'm
Mike
Jones,
just
speaking
as
me,
I
wanted
to
respond
to
your
comment
about
Python,
because
one
of
the
people
I
work
with
very
closely
Roland
Hedberg
in
Sweden,
run
open
ID,
connect,
test,
suite
and
python
that
uses
standard,
lay
available
libraries
and
uses
all
these
stuff
works
in
revealing
one
of
the
things
we
did
in
the
Jose
working
group.
When
deciding
what
algorithms
to
recommend.
J
G
B
G
G
J
Then
we
could
take
that
as
a
starting
point.
Thank
you
very
much.
We
can
take
those
a
starting
point
if
there
are
people
that
want
to
revisit
any
of
the
findings
that
are
in
there
because
we're
a
couple
of
years
later,
I
would
be
completely
appropriate
to
do
so
without
d
railing,
the
thought
sure
so
do
we
have.
We
don't
have
to
make
a
decision
on.
G
B
G
B
Lovely
as
well
be
awesome
because
one
thing
I,
one
reason
that
I
asked
for
that
is
when,
when
we
sat
down
and
talked
about
the
encryption
stuff,
we
worked
out
that
the
record
layer
that
the
GCM
application
is
merely
a
profile
of
JW.
If
you
think
about
it
from
some
perspectives,
you
again
provided
a
particular
header
to
jwe
and
then
just
take
the
header
away
again
and
drop
the
the
message
payload
in
so.
G
B
That
easy
yep
in
this
case,
that's
what
AAA
ds4.
So,
let's,
let's
get
that
information
will
have
the
discussion
on
lists
and
try
to
come
to
some
sort
of
conclusion.
On
that
all
right.
Five
minutes,
david
benjamin
raised
this
issue.
I
may
have
trouble
explaining
the
details
of
this,
but
to
the
extent
that
a
user
agent
is
able
to
authenticate
the
application
server
that
sent
a
message,
we
rely
on
two
things.
B
Yes,
this
message
really
did
come
from
the
person
food
I
gave
this
this
information
out
to,
and
so
what
this
would
entail
would
be.
A
bucket
of
bits
would
be
given
alongside
these,
the
URI
and
the
diffie-hellman
chair
to
the
application
server
in
the
application
server
would
carefully
ship
that,
up
to
its
instance
in
the
cloud
now,
it
wouldn't
necessarily
need
to
be
a
bucket
of
bits.
That's
needs
careful
encoding.
B
One
of
the
concerns
that
David
raised
was
that
doing
something
like
base64
encoding
is
not
constant
time,
so
you
don't
do
it
on
private
key
material.
That's
a
comment
for
Jose
by
the
way,
and
you
would
give
them
maybe
a
string,
and
you
would
take
that
string
and
you
would
shove
that
into
a
hash
Mac
on
the
application
server
side
over
some
piece
of
information
that
was
unique
to
the
message.
It
could
be
the
salt,
it
could
be
the
public
key.
It's
using.
F
B
B
C
As
you
know,
what
40
cm
we
plan
for
thursday
Christine,
who
will
put
put
juicy
and
our
implementation
we
plan
to
require
out
a
separate
education?
I.
Don't
think
we
have
any
part
where
we
wouldn't
have
second
authentication,
not
sure
which
form
and
it
can
be
different
draft
in
a
different
discussion,
but
I
think
it's
critical
for
many
and
when
we
discussing
the
mechanisms
different
reasons,
fine.
B
So
maybe
maybe
we
can
just
park
this
one.
If
no
one
has
any
strong
feelings
on
it,
we
can
take
a
look
at
the
proposal
that
I
think
you're
really
going
to
come
up
with
and
say
whether
or
not
we
can
use
that
aspect
of
it
to
deal
with
this.
It
may
be
the
case
that
that
is
insufficient
for
the
case
that
over
concept
decima,
you
want
to
ask
a
question.
No.
F
F
F
D
So
I'm
tell
the
colonel
from
cannon
and
I
really
like
to
talk
about
energy
requirements
forward.
So
next
slide,
please
so
we
good
to
disease.
We
would
like
to
reserve
to
receive
a
notification
from
the
clouds
or
from
the
servers,
for
example,
for
camara
to
receive
notification
from
a
photo-sharing
service
of
our
printer.
We
see
notification
from
a
server
when
there
are
new
files
or
new
document
to
print.
D
D
It's
required
by
Sony
to
the
intermediaries
to
keep
the
connection
open
and
from
a
paper
formal
2011
from
one
they
found
that
in
15
persons
of
iced
teas
have
a
timeout
less
than
10
minutes.
I
think
the
study
was
done
in
the
US
and
with
this
increases
energy
consumption
by
ten
percent.
So
for
us,
from
our
point
of
view,
we
we
don't
want
that
a
certain
program
is
HTTP
to
ping,
so
the
pink
could
be
dude.
D
You
go
forever,
for
example,
for
push
lever
to
take
in
the
HTTP
connection
or
more
or
less
the
HTTP
to
connection
still
alive,
and
it
could
generate
an
unnecessary
practice
in
increasing
energy
consumption.
So
we
would
ensure
that
this
doesn't
happen
with
web
push,
and
last
thing
is
a
consecutive
notification
with.
D
We
think
that
there
should
be
grouped
to
use
the
same
active
period
of
the
violence
of
system
so
that
we
don't
have,
as
in
the
top,
every
notification
waiting
the
wireless
subsystem,
letting
it
go
to
sleep
again
and
then
the
next
notification
waking
every
day.
So
it
could
be
useful
to
have
something
similar
to
the
teen
idol
algorithm
to
group.
Several
notification
in
one
waiting
period
of
the
wireless
system,
so
that's
it.
We
were
welcome
to
source
or
any
other
comments
on
this.
J
J
Alright,
so
in
practice,
Matt
Matt's
about
stand
up
behind
me
and
correct
me,
but
like
we've,
we
found
in
x
and
p
p8
if
these
are
basically
completely
useless
in
practice.
So
yeah,
it's
not
not!
So
if
you
need
to
do
this,
you
basically
have
to
do
it
up
at
that
at
the
application
layer
have
something
that
you
can
send
and
and
probe
even
worse.
J
You
like
you
need
to
get
a
response
back,
because
otherwise
you're
waiting
for
something
like
11
or
17
minutes
to
know
that
the
TCP
socket
is
dead
when
all
the
timers
timeout.
So
it's-
and
this
is
one
of
those
things-
there's
no
good
solution
for.
Unfortunately,
unless
you've
got
like
some
help
from
the
network.
A
Yeah,
so
this
is
very
interesting
playing
on
battery
for
many
years
now,
weird
GCM.
We
chased
every
single
operator
in
the
in
this
planet
to
raise
that
time
out,
some
of
them
they're
still
not
playing
with
us,
but
the
best
ones.
We
have
like
an
hour
to
play.
The
best
solution
would
be
making
some
years
from
now.
If
ipv6
is
everywhere
and
then
we
can
just
point
the
device,
no
need
for
her
boots,
there's
all
the
batching
that
it
is
done.
A
You
know
there
are
like
also
options
like
priority,
because
not
everything
you
want
to
wait
to
maybe
for
the
camera,
it's
okay
to
wait
for
every
message
very,
but
if
you
have
like
a
voice
of
our
people,
wanna
be
instantaneous,
but
that'd
be
like
a
lot
of
things
that
can
be
done.
I
would
say
at
a
push
service
implementation
that
does
a
commendation
for
battle.
G
Matt
Miller
so
as
as
Joe
is
eluding.
What
what
we
have
found
with
devices
is
TCP
time.
Tcp
keep
alive
was
it
was
useless,
and
what
we
also
found
is
that
usually
something
between
our
server
and
the
client
would
kill
things
within
30
seconds
so
about
every
30
seconds.
We
would
have
to
send
something
and
it
seemed
to
be
very
universal
now
for
a
push
service
with
a
camera
back
to
a
very
well-known
device.
J
Worst
of
those,
this
is
Joe
pretend
I'm
on
the
floor.
The
worst
of
those
wouldn't
send
offend
or
reset
when
they,
when
they
drop
this
date
for
the
connection,
and
so
the
softest
was
just
dead,
but
you
had
no
way
of
knowing
until
it
was
17
minutes
from
now
and
too
bad,
and
so
both
sides
needed
to
be
sending
these
people
lives.
In
order
to
find
out
that
the
socketed
item
is,
it
was
4pm
exactly.
G
That
anyways-
and
it
really
was
every
30
seconds
now-
that's
between
the
application,
server
and
the
client
again,
if
you
can
rely
on
some
other
way
of
doing
the
notifications
that
doesn't
require
that
channel,
like
the
application
server
to
the
push
server
is
well
well
established
enough,
I
mean
there's.
Most
people
can
get
that
network
setup
that
it's
not
an
issue
right
I'm.
They
don't
have
to
worry
about
keep
alive
and
have
to
worry
about.
The
whitespace
pings
will
be
used
in
XP.
G
C
J
E
Yeah,
currently,
the
web
portion
is
a
center
and
the
notion
sell
subscriptions
the
foundation
for
web
poor
and
these
are
for
SME
good
result.
There
is
no
question
that,
however,
it's
also
true
that
in
the
new
schedule
and
give
you
a
few
example,
some
of
the
of
those
reasons
could
conceivably
be
using
Apple
and
helping
in
common
desire
use
cases.
So
if
it
so
I'm
just
kidding,
for
example,
I
think
there
are
more,
but
a
disaster
of
the
depositor
not
currently
dealing
with
and
if
s1
is
a
simplest.
F
E
Very
poor
solution,
right
now
and
in
some
of
our
pilots
you're
actually
using
web
push
with
the
moderate
success.
If
big,
actually
a
much
brighter
successfully,
we
wouldn't
require
the
various
subscription
or
over
a
bit
of
a
different
notion
of
a
service
absolution.
The
other
important
use
case
is
like
local
maps
and
the
it's
not
just
the
buildings
on
fire
I
said
can
be
a
missing
child.
There
are
a
number
of
situations
where
the
important
the
value
of
information,
what
are
actually
the
cost
of
not
getting
information
in
suraíh
that
it
pm's
said
anything.
E
Example
in
exchange
of
being
firm,
so
a
lot
of
notification
is
a
permanent
examples
that
there
are
a
few
other
oral
skills
to
go
to
the
next.
A
similar
situation
is
in
setting
very
particular
is
not
buildings
of
venues
where
the
user
has
a
clear
expectation
that
entering
the
building.
There
is
a
some
type
of
provider
that
actually
owns
become
thinking
of
using
and
provide
services
through
that
building,
so
in
those
recitation,
the
user
expectation
might
be
in
privacy.
E
And
finally,
one
issue
that
you
are
seeing
in
the
commotion
of
subscription
is
the
file
of
the
users
are
sensitive
to
the
globe
volume
of
pushes
and
regards
very
difficult
entrusted
to
police
off,
to
regulate
the
global
volume
across
application
that
are
hitting
a
user,
and
so
did
two
things
once
a
break.
I
got
a
notion
of
web
push
type
of
traffic
until
a
notion
of
fairness
on
our
room
to
the
regulator.
E
F
E
Traffic
in
it
and
in
exchange
of
the
user
exciting
not
to
ever
in
mystic
subscription,
the
user
would
expect
that
there.
It
would
not
be
hit
by
300
the
message
or
the
PA
frequency
regulation
or
homes.
Some
type
of
a
mechanism
on
in
that
fashion.
And
if
you
have
this
mechanism
and
the
notion
of
having
applied
globally
and
controlling
to
be
also
have
anything
that
we
could
use
it
to
actually
love.
F
E
F
K
Then
return
actually
I
agree
with
all
the
use
cases.
The
only
problem
is
that
there
is
a
different
terminology
for
them
and
a
coke
broadcast
and
you're
basically
doing
client-side
subscription
and
it
it
probably
is
a
different
pattern
and
I
believe
it.
It
has
a
totally
different
set
of
issues
associated
with
well
with
them,
because
it's
different.
So
if
we
look
at
it,
this
subscription
less
is
broadcast.
So
that's
what
I
think
I
think
we
you
described
all
these
cases
that
apply
to
broadcast
and
we
got
a
LT
broadcast.
You
know
we
do.
F
Guys
can
talk
to
each
other
after
the
meeting,
so
we
got
one
minute
left,
I
just
wanna
just
so
when
we
get
when
we
consider
adopting
a
protocol
drop,
we
actually
decided
to
not
include
the
encryption,
esta
de
la
dropped
and
I
guess
what
I
want
to
ask
is:
do
people
have
any
issues?
If
you
do
decide
to,
you
know
include
the
encryption
drop
is
part
of
the
quad
draft,
or
do
we
want
to
create
another
milestone
for
thank
you
should
have.
H
Besides,
the
I
want
to
raise
the
problem
of
some
IOT
cases
where,
in
general,
I
think
that,
if
like
Francisco
was
saying
earlier,
you
have
that
the
device
is
actually
part
of
the
application.
So
the
user
agent
is
not
an
intermediate
notion
to
his
effectively
no
need
for
a
vote
for
an
encryption
standard.
Now,
I'm
actually
not
opposed
to
it.
In
any
way.
However,
there
could
be
some
cases
where
we're
mandating
certain
crypto
algorithm
on
a
device
which
could
be
constrained.
It
could
actually
pose
a
problem
and
so
that
just
that
is
busy.
F
F
E
F
A
B
Yes,
on
Tom
tonight,
I,
don't
actually
mind
work
lives.
There
may
be
some
editorial
conveniences
and
we
can
get
by
having
the
split
I.
Don't
know.
This
will
be
man.
This
will
be
mandatory
for
the
w3c
spec,
but
we
can
make
a
separate
choice
regarding
must
use
or
not
here
for
the
protocol
uses,
because
we
do
actually
have
a
broader
set
of
use
cases
that
they
will
bring
in
here.
G
Matt
Miller,
it
might
be
interesting
to
think,
while
still
making
this
mandatory,
because,
like
said
the
w3c
and
there's
a
whole
raft
of
cases
where
in
crypto
crypto
here
is
going
to
be
absolutely
mandatory,
it
might
be
worth
thinking
of
it
as
a
separate
draft
to
allow
for
some
freedom
as
cryptic
as
the
state
of
cryptography
improves
that
we
might
want
to.
Let
ourselves
give
us
our
up
some
breathing
room.
We
specify
something
now
at
one
level,
we
can
update
later
as
things
improve.
F
J
It's
likely
that
the
two
things
of
being
able
to
have
a
separate
editor
for
this
chunk
of
the
draft
and
then
being
error
able
to
paralyzed
work
a
little
bit
I.
Think
probably
we
ought
to
keep
them
separate
for
the
moment.
We
can
always
recombine
them
later.
If
we
decide
that
it's
easier
to
read
or
process
or
whatever
yeah,
so
we
don't
have
to
make
a
decision
just
yet.
We
may
also
decide
at
the
end
that
Matt's
point
of
keeping
it
separate
allows
us
to
rub
the
crypto.