►
From YouTube: IETF95-WEBPUSH-20160404-1740
Description
WEBPUSH meeting session at IETF95
2016/04/04 1740
A
C
A
C
D
C
C
C
C
C
G
Okay,
so
just
to
cover
what
we've
done
since
the
last
ITF
that
we
published
two
drafts,
there
was
some
discussion
from
Canon
on
a
scenario
related
to
subscription
sets.
You
may
recall
that
we
started
with
the
ability
for
the
server
to
provide
a
subscription
set
and
the
server
was
making
all
the
decisions
on
to
allow
the
aggregation
of
subscriptions.
G
G
In
addition,
at
the
last
IETF
we
talk
about
message
collapsing
or
message
updates.
So
basically
you
have
an
outstanding
message
that
hasn't
been
delivered
to
the
user
agent,
and
now
there
is
an
update
to
that
perhaps
number
of
mail
messages
or
something
of
that
sort.
Now
you
can
do
another
post
to
a
particular
topic
that
that
belonged
to
and
replace
that
message
and
basically
delete
it.
That
has
been
added
for.
G
In
addition,
we
added
pushed
message
urgency
which
allows
an
application
server
to
indicate
what
it
believes:
an
urgency,
a
message
very
low,
for
example,
for
an
advertisement
higher
for
other
messages.
Then
it
also
allows
a
user
agent
to
filter
on
that
urgency.
To
basically
say
I,
don't
want
to
wake
up
for
an
advertisement.
Wake
me
up,
for
you
know
very
important
message
so.
G
I
J
J
H
G
There's
the
thunder
and
client
authentication
issue
jump
up
which
is
potentially
addressed
by
vapid
if
adopted
and
Martin
will
be
talking
about
that
in
a
bit.
I
wanted
to
make
some
editorial
changes
to
the
security
considerations.
Sections
just
have
informative
references
to
both
the
content,
encryption
draft
and,
if
adopted,
the
authentication
draft,
maybe
include
some
principles
again
they're
being
covered
by
Martin
and
then
finally,
there's
the
issue
of
simplifying
acknowledgments,
which
has
been
discussed
on
the
mailing
list,
and
most
of
my
presentation
is
going
to
be
about
that.
G
During
the
subscription
for
messages,
the
user
agent
gets
back
a
number
of
link
relations.
One
of
those
is
the
push
link
relation
which
is
used
to
buy
the
application
server
to
send
messages
through
the
push
service
to
the
user
agent.
The
other
is
receipt
subscription
the
push
colon
receipts
both
of
those
need
to
be
distributed
to
the
application
server.
The
application
server
then
uses
the
push
receipts,
link
relation
to
request
a
subscription
for
receipts
slide
and
the
new
proposal.
We
can
basically
yeah
it's
great.
G
G
G
G
G
You
will
provide
your
subscription
in
the
post
with
a
message
to
indicate
that
you
want
to
get
a
receipt
and
that's
where
the
acknowledgement
should
be
returned
to
you'll,
get
your
201
location
of
your
message
and,
if
you're
monitoring
at
some
point,
you're
going
to
receive
a
receipt
and
we've
agreed
to
a
204
and
then
a
path
to
the
original
message
that
was
created
by
the
and
returned
by
the
push
service.
Next
slide.
G
G
G
G
G
So
looking
at
it
today,
the
best
case
scenario
is
if
a
user
agent
gets
back
a
push
resource
from
its
push
service
and
distributes
it
to
one
application
server,
which
I
think
is
the
default
expectation.
But
it's
not
required.
Could
you
hand
it
off
to
as
many
servers
as
it
wants?
The
push
service
should
be
able
to
return
the
same
status
monitor
if
you
will
the
same
receipt
for
message:
delivery
request
from
an
application
server
to
the
same
push
resource.
G
G
G
H
G
B
G
L
B
L
G
B
B
L
B
B
L
B
B
B
E
E
B
L
M
L
It
needs
to
do
in
order
to
get
that
if
mate
could
then
decide
to
send
you
the
same
your
eye
in
responsible-
and
you
might
be
sad
as
a
result
of
that,
because
now
you're
getting
receipts
for
something
over
here,
where
you
actually
wanted
them
over
here,
because
it's
made
some
inference
about.
What's
going
on.
L
L
O
O
L
So
so
that
the
way
we
do
subscription
sets
right
now
is
that
when
you
request
a
subscription,
you
say,
and
by
the
way
I
have
this
subscription
set
already,
if
it
makes
sense
for
you
to
do
so.
Please
put
the
subscription
in
this
set
and
you
would
make
the
same
request
in
this
case.
You
would
say,
oh
by
the
way,
I
already
have
this
receipt
subscription
set
over
here.
If
it's
convenient
for
you
use
it
you're.
B
B
M
B
L
G
L
To
toss
something
right-
and
I
think
that's
again-
that's
that's
a
good
good
way
of
dealing
with
that
as
well
yep
that
fits,
and
we
don't
have
to
define
any
actual
mechanisms
for
that
to
work.
We
just
go.
This
is
this
thing
over
there
on
this
thing
over
there
and
we're
just
like
glue
them
together,
yeah.
C
J
Patrick
Olinsky
Francisco
I
I,
liked
everything
I
liked
pretty
much
everything
in
the
new
in
the
new
draft
that
which
I've
read
that
I
haven't
read
hundreds
anivia,
but
I
think
that
we
should
be
looking
at
a
closer
into
how
we
can
use
urgency
for
a
couple
of
additional
semantics,
in
particular
around
prioritization
and
potentially
around
some
of
the
subscription
stuff.
His
as
Martin
was
bringing
up
around
subscriptions
and
kind
of
guiding
the
the
server
to
the
description
to
the
right
server.
B
L
L
D
B
D
L
L
So
we
have
this
request
that
push
servers
were
unhappy
with
the
situation
that
they
weren't
able
to
do
anything
at
all
to
identify
the
application
servers
in
some
sort
of
standard
way,
and
so
this
draft
does.
It
basically
puts
a
very
minimalist
beyond
this
one.
We
we
requested
application
servers
generate
themselves
a
signing
key
and
that
they
generate
a
a
token
and
they
they
can.
L
We
ask
they
put
an
expiration
time
in
there
and
then,
if
they
want
to,
they
can
put
their
email
address
or
a
link
to
contact
details
on
the
website
somewhere.
This
has
actually
made
some
of
our
privacy
people
a
little
bit
nervous
because
we're
actually
going
to
store
this
information
now
and
storing
contact
details
is
not
the
greatest
thing.
L
L
I
I
L
L
This
is
the
month
I'm
the
best
feature,
which
means
that
I
can
deploy
my
application
and
no
with
some
reasonable
degree
of
certainty
that
only
my
push
server.
My
application
servers
are
going
to
be
able
to
push
messages
to
that
application,
and
the
push
service
will
reject
attempts
to
push
to
those
subscriptions.
We
really.
Q
L
Q
L
J
Think
it's
just
going
to
be
a
crew
service
choice,
okay,
I
just
it
would
be
this.
It
would
be
unfortunate
if
we
wrote
this
back
in
such
way
that
the
rejection
is
mandatory.
It's
currently
mandatory,
okay,
I
think
would
be
useful
to
allow
the
respect
to
allow
that
behavior
so
that
you're
not
out
of
specs.
If
you're
dropping
yeah
I.
L
B
M
K
K
D
K
L
K
L
L
B
L
B
L
B
B
B
L
G
L
About
it
was
that
the
the
voluntary
contact
information-
that's
in
that's
included
in
this
token,
is
as
home
to
Ali
unauthenticated
things.
I
can
provide
Joe's
email
address
in
the
token,
and
the
push
service
will
probably
happily
accept
that
until
such
time
as
Costin
is
looking
at
that
the
number
of
messages
that
I
generated
and
sends
an
email
to
Joe,
saying
hey,
why
the
hell
are
you
sending
so
many
messages
and
Joe
goes
or
it
lands
in
Joe's
spam
bucket
or
something
like
that
and
disappears
so
they're.
I
L
D
L
Automated
on
some
server
that
is
going
to
receive
the
responses
from
the
push
service
and
just
play.
Oh
look
at
that
too.
I
too
great
proceed.
It's
not
going
to
have
any
way
to
feed
that
motion
back
to
the
person
that
wrote
the
code
or
the
person
that
I
would
put
that
that
string
in
there.
But
what
might
happen
there
is
that
in
in
some
circumstances
the
push
service
might
gate,
greater
access
to
capacity
or
features
or
something
or
other,
on
being
able
to
contact.
L
Someone
and
say,
look
you're
sending
a
lot
of
messages
in
we're
now
giving
you
a
worse
class
of
service,
then
you
could
get.
Can
you
please
confirm
the
traffic
that
you're
sending
me
is
legitimate
and
we'll
have
that
conversation,
and
then
you
can
turn
it
on.
That's
the
sort
of
thing
that
we
see
is
being
useful
more
than
anything
else,
and
probably
the
most
important
use
for
it
is
all
of
a
sudden.
Your
your
particular
application.
Server
has
gone
from
standing,
I,
don't
know
a
thousand
messages
an
hour
to
a
thousand
messages,
a
second.
D
L
L
D
L
C
C
G
C
D
L
So
because
I
want
to
wasn't
expecting
spanners
in
the
last
meeting,
so
we
had
discussion
about
the
encrypted
content,
encoding,
stuff
and
Decker
observed
that,
if
we're
going
to
do
signing
for
other
reasons
in
HTTP
and
we're
doing
encryption,
there
are.
There
are
interesting
interactions
between
signing
and
encryption
that
need
to
be
very
carefully
considered.
L
Basically,
the
basic
problem
is
that
you
can't
do
signing
and
encryption
as
two
separate
steps
and
expect
the
overall
thing
to
be
safe,
because
you,
depending
on
which
order
they're
applied
in
one
or
other,
can
be
removed
to
replace
both
by
something
else.
And
this
there's
a
bunch
of
research
on
this
and
how
you
manage
it.
L
I
haven't
thought
through
all
the
implications
of
that,
but
it
will
likely
delay
the
content
in
coding
stuff
until
such
time
as
we've
reassured
ourselves
that
there
is
no
problem
so
that
we
have
sufficient
mechanisms
in
place
to
deal
with
that.
That's
now
going
to
be
the
only
thing:
that's
stopping
us
from
shipping
documents.
I.
Imagine
given
the
status
of
the
the
protocol
draft,
which
is
basically
a
handful
of
pull
requests
away
from
being
done
from
what
I
from
Brian's
presentation
and
I
have
nothing
to
do
on
the
web.
L
Push
side
of
this
stuff,
because
all
I
did
was
updated
recently
to
the
changes
that
were
but
we're
in
there
so
update
the
references
so
that
that's
where
that's
at
we're
running
on
internet
draft
at
the
moment,
I,
don't
feel
any
particular
urgency
to
publish
unless
anyone
feels
that
they
need
to
see
an
RFC
number
sooner
rather
than
later.
But
I
don't
know
how
to
play
this
one,
because
that
it's
just
there's
problems
and
we
ended
neda
something
through
so.
H
L
That
the
first
step
is
understanding
that
the
the
nature
of
the
problem
and
the
available
options
for
solving
it.
So
the
basic
the
basic
techniques
for
solving
in
a
well
understood
and
is
not
particularly
difficult
to
address
the
the
problem
is
understanding
the
application
to
http
in
the
way
that
it's
being
used
and.
L
What
we
have
at
the
moment
is
a
bunch
of
generic
tools
can
be
applied
in
any
number
of
ways
which
makes
it
very
difficult
to
understand
it
in
context.
And
so
what
we're
going
to
have
to
do
most
likely
is
is
change
the
scope
of
the
tools
that
we're
providing
in
order
to
more
narrowly
define
the
problems
that
can
be
solved
and
therefore
showing
the
problem
in
a
way
that
can
we
can
actually
solve
it.
L
C
So
when
we
adopt
this
adopted
this
continent
coding
draft,
you
know
it
was.
The
idea
was
to
progress.
The
quad
raft
and
the
continent
coding
draft
together
into
the
end,
submitted
to
a
SG
at
the
same
time
or
you
know,
making
a
diversity
at
the
same
time,
but
we
don't
really
I
mean
unless
you
know
it's
not
if
we
can
still
progress
the
quad
draft
and
then
see
what
we
need
to
what
we
want
to
do
with
the
continent.
Coding
job
depend
on
the
status
of
the
HTTPS
draft
yeah,
so
the
uncomfortable.
L
Part
there
is
that
we
don't
have
a
dependency
on
the
problem
being
solved.
It's
just
that
we
have
a
dependency
on
the
draft
that
has
a
dependency
on
having
a
problem
solved.
So
yeah
I,
like
I
said
before,
I'm
not
I'm
not
particularly
fast
about
timing.
Unless
other
people
want
to
push
push
push
on
this,
one
I
think
we
can.
We
can
afford
to
let
that
one
take
its
time,
and
it
may
just
be
that
it
requires
a
week
because
we
sit
down
and
have
a
meeting
work
work
through
the
thing
work
out.
L
What
the
what
sort
of
constraints
we
can
put
on
the
problem
space
and
write
some
text.
It
may
be
that
simple
or
it
may
be,
that
we
have
to
have
to
look
at
the
interplay
of
content,
encodings
and
there's
some
weird
new
content
encoding.
That
did
you
use.
That
is
the
combination
of
encryption
and
signing.
So
are
you
gonna
sit
down
with
echo
and
all
of
them
and
then
try
to
figure
out.
L
J
Patrick,
let's
agree:
Francisco,
yes
of
the
prioritization.
The
the
the
urgency
field
today
is
like
tantalizingly
close
to
it
to
a
to
a
message,
priority
indicator,
and
it
would
be
great
to
look
at
how
we
can
allow
how
we
can
use
it
for
that.
So
you
talk
about
a
couple
different
things
earlier.
You
know
a
delivery,
not
waking
up
the
radio
etc,
but
I
think
there
are
a
bunch
of
other
dimensions
that
that's
very
useful
to
look
at
as
well,
so
reordering
of
items
so
that
high
priority
things
come
first
on
a
reconnect.
J
Routing
differently
so,
for
example,
high
priority
items
going
to
different
set
of
servers
potentially
be
a
some
sort
of
subscription,
metadata
and
kind
of
quality
of
service
guarantees
or
not
guarantees.
But
the
targets
based
on
what
those
those
those
priorities
are
I
think
it
would
be
really
nice
to
figure
out
like
I,
don't
want
like
delay
getting
something
out
there.
J
By
the
other
hand,
I
think
that
it'd
be
really
nice
to
figure
out
at
least
one
hour
like
what's
a
list
of
the
things
that
we
would
want
to
do
with
prioritization
like
next
and
make
sure
that
we're
not
defining
urgency
in
such
a
way
that,
like
you,
know
six
months
for
now,
we're
like
oh
crap
that
not
going
to
work,
we're
gonna,
have
to
add
a
new
field.
So
I
think
that's
my
main,
but
my
main
concern.
J
There
is
a
bit
of
a
sanity
check
and,
like
some
brains
coming
around,
what
are
all
the
things
that
we
think
would
be
good
to
use
prioritization
with
what
are
the
things
we
think
would
be
not
only
good
to
use
prioritization
for,
but
would
be
beneficial
to
be
specifying,
and
how
does
that
dovetail
with
with
the
ergency
stuff?
So
that's.
J
J
So
there's
a
separation
between
like
the
the
source
of
a
message
and
the
the
priority
of
that
message
and
those
are
probably
mapped
really
nicely
into
different
subscription
classes,
but
I
I,
don't
think
we're
missing
granularity,
I'm
more
concerned
that,
like
of
the
surprise
so
I,
feel
like
it
would
be
very
worthwhile
to
go
through
the
the
exercise
to
the
degree
of
validating
that
we're
not
that
we're
not
paying
ourselves
into
a
corner
more
than
anything
else.
So.
H
J
So
I
guess
I'm
more
interested
in
the
granularity
I'm
more
interested
in
questions
around
the
interactions
of
like
subscriptions
and
prep
and
and
urgency,
for
example,
so,
mechanisms
for
a
application
server
to
be
able
to
convey
the
the
fact
that,
a
after
a
day,
a
low
priority
message
can
just
get
dropped
which
which
it
can
which,
like
we
have
a
TCL.
But
there's
like
a
cam
and
let
there
there's
this
fuzzy
barrier
between
like
I,
don't
really
care
if
you
drop
it
like
the
like
drop
these
ones
first
kind
of
like
so.
J
If
I
have
a
bunch
of
high
priority
stuff
coming
in
then
like
I'd.
Rather,
you
make
the
experience
really
great
for
the
high
priority
stuff
and
the
TTL
I'd
like
it.
If
you
had,
if
you
could
deliver
this
within
this
TTL,
but
but
you
don't
necessarily
need
to
so.
Those
are
those
sorts
of
interplay
between
the
features
are
what
I'm
concerned
about
more
than
the
granularity
of
the
feature
itself.
J
D
J
J
J
D
All
right
so
there's
there's
three
half
raised
for
half
raised
hands.
Okay,
so
if
you
can
get
with
them
and
make
some
progress
on
this
quickly,
I'd
say
great.
I
will
I
don't
I'm
not
saying
enough.
Other
people
jump
up
and
down
and
say
this
is
massively
ortant
that
we
necessarily
ought
to
hold
up
the
group.
J
J
L
So
one
of
the
one
of
the
results
of
such
a
discussion
could
be
that.
Well,
we
have
something.
It
may
not
be
ideal.
We
need
to
work
on
some
other
things.
What
we
can
do
them
later.
That
would
be
a
great
outcome
in
my
opinion,
but
we
need
to
make
sure
that
we
haven't
painted
ourselves
into
a
corner.
Yes
and
I.
O
L
My
my
analysis
that
I've
done
privately
without
the
benefit
of
Patrick's
perspective
is
that
I
think
we
can
do
some
of
the
things
that
you
want
to
do
or
likely
what
to
do
because
I'm
guessing
based
on
what
you
told
me
without
materially
changing
what
we
have
currently.
However,
there
may
be
some
other
things
that
you
want
to
do
that
I,
don't
know,
I
don't
understand
very
well,
and
so
we
have
that
conversation.
R
Alyssa
Cooper,
it
might
also
imply
that
other
people
who
are
going
to
review
this
again,
one
more
time,
think
about
extensibility
and
how
how
the
draft
deals
with
extensibility,
because
that
might
be
a
nice
way
around.
This
is
like
as
long
as
people
feel
comfortable
that
you
I
mean
right
now
they
are
just
a
mechanism.
Doesn't
is
not
extensible
right,
but
that
might
be
fine,
but
just
generally
thinking
about
the
points
where
extensibility
might
help,
then,
if
you
feel
more
comfortable
that
in
the
future,
this
isn't
boxing
you
in
little
corner
I.
Think.
D
That's
a
fantastic
suggestion
so,
for
example,
being
able
to
determine
what
extensions
are
currently
deployed
on
this
server.
That
kind
of
thing
I
mean
we've
had
that
in
a
variety
of
other
protocols.
In
the
past,
it's
been
really
useful
to
get
out
of
these
kinds
of
things.
It
would
be
nice
to
not
have
to
do
eh
ello,
just
to
add
options
later.