►
From YouTube: IETF109-HTTPAPI-20201120-0730
Description
HTTPAPI meeting session at IETF109
2020/11/20 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
All
right
so
then,
the
only
slides
that
we
have
to
share
are
the
the
chair
slides
all
right.
Well,
it's
on
time.
Let
us
I
want
to
start
well.
Let
me
I'll
start
with
sharing
the
slides.
Once
once
I
see
the
slides,
I
can't
see
the
meat
echo
thing,
so
I'm
going
to
start
with
a
poll
we
have
about
36
yeah.
A
We
have
35
people,
participants
and
so
you'll
notice,
just
below
the
in
the
upper
left-hand
corner,
there's
a
show
of
hands,
and
so
I'm
going
to
just
take
a
straw
poll
and
it's
it's,
and
so
the
question
is
we
want
to
know
is:
are
you
familiar
with
the
ietf
process?
The
way
it
works?
If
you
are
raise
your
hand,
if
you're
not
don't
respond
or
do
not
raise
your
hand
and,
depending
on
the
number
of
you
know
no
votes,
we
get
that'll
indicate
how
much
as
we're
going
through
this
meeting.
A
You
know
how
we
do
things
and
what
it
is
so
emnot
and
other
people
said
50
and
so
far
it's
currently
running
about
that.
We'll
wait
another
10
seconds
and
see
which
means
to
me
that,
as
we
talk
about
the
things
use
the
raise
your
hand
tool.
While
I'm
explaining
something,
if
something's
not
clear,
we
don't
want
to
turn
this
all
into
a
you
know,
process
discussion.
A
All
right
so
there's
the
the
vote.
People
can
see.
Well,
two-thirds
are
familiar
so
I'll.
Do
you
know
abbreviated,
intros
and
feel
free
to
mention
something?
You
can't
do
it
in
the
chat
because
I
won't
see
it
easily
but
offline.
A
You
know,
or
after
I'm
done
or
just
raise
your
hand
a
week.
You
know
start
talking
so
with
that
I'll
share
my
screen
and
let
us.
A
Every
working
group
in
the
itf
is
organized
into
an
area.
Each
area
is
run
by
two
or
more
area
directors.
Basically,
barry
liba,
who
you'll
see
in
the
participation
is
our
area
director.
He
is
the
person
who
we
will
turn
to
who
he
is
chairs
will
turn
to.
If
we
have,
you
know,
process
questions
or
something
like
that.
A
Okay,
next
page,
the
no
well,
everything
in
the
ietf
is
done
under
a
particular
set
of
intellectual
property.
A
They're
documented
in
what's
called
a
bcp
document.
A
bcp
is
a
number
that
doesn't
change,
even
if
you
know
it's
a
level
of
indirection
right
typical
computer
science
solution.
There
are
so
there
are
a
couple
of
bcps
that
describe
the
standards
process.
How
working
groups
work?
A
We
have
anti-harassment
and
code
of
conduct
processes.
You
know
don't
be
a
jerk.
If
you
are
a
jerk,
we
will.
There
are
options
available
to
us,
there's
dispute
resolution
and
so
on.
If
you
disagree
with
what
the
chairs
are
doing,
you
can
speak
to
barry.
A
If
you
disagree
with
what
he's
doing,
there's
escalation
processes,
the
two
two
of
the
important
intellectual
property
processes
are
about
copyright.
When
you
present
a
document
for
the
working
group
to
adopt,
which
means
the
working
group
takes
the
ownership
of
it,
that
is,
transferring
the
copyright
of
that
document
to
the
ietf
patents
and
participation.
A
You
agree
that
if
you
are
aware
of
patents
that
affect
the
things
that
the
working
group
is
working
on,
that
you
will
inform
the
working
group
or
you'll
phone,
the
itf
that
you're
aware
of
patents,
the
idea
being
that
you
can't
sit
there
and
help
develop
a
standard
and
then
the
patent
gets
you
know
disclosed
after
things
been
adopted
and
and
published
the
way
we
control
that
is
through
what
we
use.
We
use
the
term
blue
sheets
when
we
meet
in
face
to
face
we
hand
around
blue
colored
sheets
of
paper.
A
Everybody
signs
them
and
that
shows
who
attended
the
meetings
and
it
acknowledges
that
you
agree
that
you've
read
you
understand
and
you
agree
to
abide
by
the
note.
Well,
the
note.
Well
sorry
for
the
virtual
meetings
when
you
signed
in
to
do
to
join
the
meet
echo
participation,
then
you
are
that's!
That's
your
signature.
It's
an
electronic
signature!
Okay,.
A
This
meeting
is
being
recorded.
It
will
show
up
on
youtube
shortly
after
the
the
meeting
is
finished
in
the
ietf
channel
shortly
after
depends,
of
course,
on
you
know,
time,
zone
differences
and
so
on.
A
Administrative
tasks,
typically
called
administrative
administrivia
blue
sheets
happen.
As
I
said
automatically.
We
need
some
volunteers.
Note
takers,
that's
being
handled
in
the
kodi
md,
it's
an
ether
pad
you
get
the
pad.
We
used
to
actually
use
etherpad.
Now
we
use
codemd.
Do
I
have
anyone
who
will
volunteer
to
take
minutes?
D
A
Thank
you
very
much.
Hopefully
there
will
not
be
a
lot.
The
the
template
for
the
minutes,
as
you
go
to
the
cody
is
already
in
there,
and
hopefully
you
know
minimum.
We
just
want
to
record
action
items
and
decisions
taken
by
the
group
of
course
courses.
You
know
that
again
telling
the
third
of
people
who
haven't
been
here
before
other
people
can
log
into
the
kodi
md
session
and
feel
free
to
make.
You
know
comments
and
corrections
and
additions.
A
Jabra
scribe
the
jabber
is
a
messaging
protocol.
You
know
I
n
protocol,
it's
already
gatewayed
to
into
the
meat
echo
visual
display
somebody
who
is
following
along
what
they
need
to
do
is
if
somebody
says
mike
mic
at
the
start
of
what
they
say.
That
means
we'd
like
you
to
they're,
asking
you
as
the
jabra
scribe
to
verbally
relay
that
into
the
meeting.
A
If
you're
the
jabra
scribe,
you
automatically
get
to
jump
ahead
of
the
queue
when
you
are
relaying
people
who
aren't
putting
themselves
in
the
queue
to
speak.
So
is
there
someone
willing
to
be
a
jabra
scribe?
It
has
so
far.
All
this
week
it's
been
pretty
zero
effort
or
close
to
zero.
I
could
I
can
do
that
for
you,
okay,
and
that
was,
I
think,
catch
the
voice
who
said
who
volunteered
mark
hi?
Oh
hey,
okay,
hey
thanks,
mark
getting
off
easy
all
right
the
agenda,
so
we
have
the
administrative
stuff
agenda.
A
Bashing
is
where
we
look
through
the
agenda
and
say
other
things.
We're
missing
are
the
things
we
want
to
add.
I'm
not
expecting
any
major
changes,
but
does
anyone
have
any
suggestions
as
to
what
you
know
any
changes
they
want
to
make.
E
A
E
Th,
this
group
is
a
little
bit
unusual
in
that
the
charter
doesn't
contain
milestones
of
deliver.
This
draft
deliver
that
draft
deliver
that
draft.
It's
like
the
http
working
group
where
the
group
you
know
goes,
and
you
know
at
least
the
charter
is
set
up
so
that
the
group
goes
and
decides
what
it
adopts
and
checks
with
the
80
and
does
it
so
that
might
be
a
little
unusual
for
some
folks
sure,
okay,.
A
All
right,
I'm
going
to
give
a
two
sentence:
introduction
about
mark's
relevance
to
this
working
group
and
then
I'll.
Let
him
explain
what
the
process
is
like.
Every
working
group
has
what's
called
a
charter.
The
charter
describes
what
the
group
is
to
work
on
it.
Often
it
can
also
describe
what
the
working
group
is
not
going
to
work
on
and
say
this
is
out
of
scope.
A
Charters
evolve
over
the
course
of
the
lifetime
of
the
working
group,
and
the
way
that's
done
is
the
working
group
says
we
want
to
amend
the
charter
to
discuss
this
new
thing
that
we
hadn't
anticipated
before
the
working
group
agrees.
They
want
to
make
that
change,
and
then
that
gets
approved
by
the
area
director
and
the
collection
of
area
directors
known
as
the
iesg
changes
in
charter
are
filtered
out
to
the
whole
ietf
through
an
ietf
wide
mailing
list
named
ietf
ietf.org,
which
anyone
can
join,
and
then
the
charter
is
approved.
A
Typically
in
a
charter.
There
are
things
milestones
attached
that
says.
Oh
by
mid-2021,
we
will
have
determined
an
initial
set
of.
A
Things
to
work
on
by
the
end
of
2021,
we'll
have
first
drafts
and
by
the
end
of
202,
by
mid
2022,
will
have
sent
the
first.
The
documents
up
to
the
isd
to
review
milestones
are
aspirational
and
they
also
evolve
over
time
and
they
can
be
changed
by
the
chairs
in
conjunction
with
their
area
directors.
E
Sure
so,
when,
when
we
proposed
the
charter
for
this
group,
you
know
part
of
the
impetus
was
that
while
we
did
drafts
like
what
we're
talking
about
here
once
in
a
while
in
the
http
working
group,
it
wasn't,
you
know
it
was
difficult
to
balance
the
the
different
communities
there
they're
slightly
different
communities
and
specialities,
and
we
felt
like
it.
E
There
might
be
some
some
benefit
to
having
it
separate,
distinguished
community
and
working
group
to
talk
about
http
apis
and
try
and
push
the
ball
forward
on
that,
and-
and
so
my
hope
is-
is
that
this
group
is
going
to
form
a
community.
I
won't
say
the
community,
but
a
community
of
people
who
are
working
on
specifications
that
help
you
know
htv
apis
become
more
interoperable
and
more
functional
for
folks,
and
so
when
we
chartered
it,
it
was
deliberately
chartered
in
much
different
way.
E
The
http
working
group
is
where
it's
an
open
remit.
You
know
the
group
can
decide.
Well.
We
think
that
this
is
a
good
draft
to
work
on
and
so
we're
going
to
adopt
it
and
you
do
a
call
for
adoption
and
then
you
work
on
it
and
published
as
an
rfc
there
there's
you
know,
that's
a
fairly
generous
amount
of
leeway
in
the
ietf.
E
Many
most
working
groups
are
chartered
with
very
specific
deliverables
in
a
very
specific
scope,
and
so
I
think
it's
good
for
us
to
have
a
discussion
here
about.
You
know
how
we
will
go
about
doing
those
adoptions
I
mean
the
formality
we
use
in
the
http
working
group
is:
is
that
we
kind
of
get
a
sense
of
that?
E
You
know
a
draft
is
a
potential
candidate,
it's
a
candidate
for
an
option
and
we
have
some
preliminary
discussions
and
then,
if
we
think
that
it's
a
contender,
we
put
out
a
more
formal
call
for
adoption
where
people
say
whether
or
not
they
support
the
adoption
of
that
draft.
E
And
often
we
do
count
pretty
strongly
the
the
intent
of
implementers.
If
we
see
lots
of
implementers
saying
yes,
I
will
implement
that
or
I
intend
to
put
resources
into
this.
That's
a
really
good
sign
and,
and
it's
a
it's,
a
mechanism
that
we
use
to
avoid
you
know
creating
documents
that
don't
get
used.
You
know
there's
this
concept
that
I
often
refer
back
to
of
hope-based
standardization
of
well
look
if
we
standardize
something
it
will.
E
It'll
become
important
or
get
a
real
rfc
number
and
the
world
will
opt
in
everything
will
be
good
and
that's
just
not
how
the
real
world
works
becoming
a
standard
is,
is
the
you
know
the
end
of
a
process
whereby
something
gets
used
widely
and
then
it
needs
to
be
built
on
top
of
sweet,
we
kind
of
even
out
the
edges,
and-
and
so
I
I
think,
I'd
like
to
see
some
discussion
of
of
a
process
where
we
can
make
sure
that
we're
actually
working
on
things
that
are
important
and
it'll.
E
Actually,
you
know
get
implemented
and
move
the
needling
industry,
not
just
somebody's
hobby
horse
project,
although
you
know
sometimes
you
do
say:
okay,
let's
take
a
punt
and
see
if
that
thing
works
out,
because
if
it
doesn't
work
out,
it's
not
going
to
waste
a
lot
of
resources.
It's
not
going
to
cause
harm,
but
if
it
does
work
out,
it's
really
good.
That's
a
judgment
call
and
the
work.
So
the
working
group
needs
to
talk
through
all
those
different
things
and
I
suspect
we
probably
need
to
get
some.
E
Some
runs
on
the
board
first
and
get
a
working
cadence
going,
and
so
it's
great
that
we
have
a
set
of
documents
that
people
have
already
brought
to
for
discussion.
So
maybe
we
just
need
to
start
working
on
those,
but
in
the
back
of
our
heads
I
think
we
should
be
thinking
about
the
next
set
of
documents
and
and
processes
to
to
make
sure
we
adopt
the
right
ones
and
get
them
and
set
them
up
for
success.
E
The
state
lives
in
that
github
repo
that
everybody
can
see
and
and
and
you
know
there
are
other
things
that
I
think
we
could
talk
about
in
terms
of
how
to
build
a
community
here-
how
to
make
sure
that
this
is
including
a
good
selection
of
the
industry,
but
but
it's
early
days.
So
maybe
maybe
we
should
just
talk
about
the
giraffes.
Now
is
that
kind
of
what
you're
looking
for
rich.
A
Yeah,
that's
exactly
what
I
was
looking
for.
Thank
you.
Mark
mark
wrote
the
charter
for
the
group
and
has
I'm
sure
almost
everybody
here
knows
mark
a
long
history
has
chaired
created.
Http
working
group
had
co-chaired
the
quick
working
group
for
years,
and
is
you
know,
he's
done
a
lot
of
work
here
and
he
understands
the
process.
He's
also
involved
with
lots
of
other
processes,
and
he
has
been
at
the
forefront
of
pushing
the
iatf
to
adopt.
You
know
these
funky
new
technologies,
like
github.
E
Yeah
charter
has
a
built-in
doomsday
clause
that,
yes,
we
need
to
prove
ourselves
that
we're
a
functional
and
and
productive
group
within
an
amount
of
time,
and
if
we
don't
do
that,
we
don't
get
renewed.
So
I
think
that's.
You
know
that
that's
a
good
motivator
until
it
becomes
a
bad
motivator,
but
you
know
right.
A
C
Yeah
hi,
this
is
barry
lee,
but
I
wanted
to
add
one
thing
to
what
mark
said
about
adopting
documents
that,
for
those
that
are
not
ietf
regulars
in
the
ietf,
when
we
accept
the
document,
it's
a
starting
point
for
development,
and
that
doesn't
mean
that
the
contents
of
that
document
are
what
will
be
in
the
standard.
It
means
that
those
are
what
are
what
the
initial
proposal
to
the
working
group
is,
and
often
there
are
significant
changes.
The
entire
document
may
change
drastically
through
the
process
of
developing
the
document.
E
E
We
can't
just
go
off
and
willingly
adopt
things,
and
I
think
it
would
benefit
you
know
putting
my
http
chair
head
on,
I
think,
would
benefit
us
and
then
the
http
work
community,
if
there's
a
good
level
of
coordination
on
draft
adoption
between
http
and
http
api,
to
make
sure
that
there's
awareness
in
both
communities
of
what
the
other
two
are,
the
other
ones
are
doing.
But
I'm
pretty
sure
we
can
do
that
at
a
chair
level,
because
we
we
know
each
other.
So
you
know
tommy
daryl.
E
If
you
don't
know
tommy,
I'm
sure
you'll
you'll
get
to
know
pretty
soon
yeah
and
I
would
I'll,
maybe
I'll,
send
a
mail
to
the
list.
We've
just
updated
our
contributing
document
in
the
http
working
group,
which
talks
about
things
like
draft
adoption
now
and-
and
I
might
send
a
message
to
a
list
to
see
what
people
think
about
that
as
a
starting
point.
You
know
I'm
not
saying
that
we
should
adopt
a
wholesale,
but
it's
some
text
that
we
might
find
useful.
A
In
jabber
and
send
us
a
list:
okay,
great
okay,
any
questions
about
what
we've
gone
through
so
far
just
speak
up.
A
F
Excuse
me,
excuse
me,
can
you
please
repeat
the
timeline
you
suggested
at
the
beginning.
F
No,
the
timeline
for
the
world,
oh.
A
A
So
yeah,
I
yeah,
don't
don't
you
know
a
month
or
two
to
adopt
some
documents?
Six
months
to
revise
it.
That's
incredibly
optimistic,
but
it's
often
what
goes
in
in
the
first
draft
and
the
area
director
will
be
the
one
nagging
the
chairs
to
come.
You
know,
update
and
fill
in
milestones,
and
the
chairs
will
then
come
to
the
working
group
and
say:
okay.
How
much
longer
do
we
need
to
do
this?
Our
job
as
chairs
is
to
keep
the
process
flowing
I'm
here,
because
I
know
how
the
ietf
works.
A
A
A
Oh
one
other
last
thing
to
lead
into
because
I'm
gonna
you'll
hear
the
phrase
everything
the
the
of
well
take
it
back.
It
depends
on
github.
We
have
many
of
the
working
groups
have
tools
to
use
github,
it
seems
like
you
know.
We
should
be
like
a
no-brainer
and
use
it.
There
is
a
github.
In
my
introductory
note,
I
pointed
to
a
document
that
described
different
models
of
how
to
use
github.
A
I
think
I'd
like
to,
let
me
just
say:
does
anyone
object
to
using
github
as
the
primary
source
of
where
the
working
group
stores
its
issues
documents
and
so
on
before
posting
the
official
updates
to
the
itf
site?
Is
there
anyone
who
has
concerns
about
using
it.
A
Okay,
I
want
to
make
sure
I
leave
enough
time
great.
What
we'll
do
is
with
mark's
help.
The
chairs
will
set
up
a
github
structure
that
has
been
used
successfully.
A
You
know
fairly
smooth,
as
mark
said,
one
of
the
things
we
want
to
do
is
we
want
this
to
be
a
major
community
for
working
on
these
areas
and
clearly,
if
you're
doing
http,
apis
and
you're
not
on
github,
then
you
are
a
niche
player,
so
we
clearly
want
to
be
on
github
I'll
end
with
the
phrase
we'll
confirm
that
on
the
mailing
list,
depending
on
how
much
we
decide
to
adopt
github,
everything
gets
officially
confirmed
by
posting
a
thing
to
the
mailing
list
and
say:
does
anybody
agree
with
this
decision
that
we
made
speak
up?
A
Let's
confirm
the
consensus
and
then
we'll
just
go
ahead.
So
our
plan
is
to
use
github
tim,
I'm
sorry
mark
and
I
and
and
daryl
will
will
set
up
a
proposed
structure
post.
Someone
will
post
a
note
into
the
to
the
mailing
list
about
how
to
do
it.
A
Okay,
the
fun
part
of
the
agenda
is
then
considering
you
know,
dress
to
consider
adopting
we'll
get
into
those
right
after
this
milestones
milestones.
Look
like
this,
we'll
have
to
figure
some
out
github
use.
We
have
an
organization
itf
working
group,
http
repository
for
document,
one
repo
for
meeting
materials.
I
like
mark's
idea
of
one
repo
for
future
work,
there's
a
set
of
tools.
All
of
this
is
documented.
A
In
you
know
the
common,
the
git
tooling,
the
git
rfc
martin
has
a
set
of
scripts
that
use
github
actions
to
format
the
documents
check
that
the
formatting
works,
publish
them
up
to
the
data
tracker,
the
ietf's
workflow
site,
there's
common
labels,
people
are
used
to
seeing
editorial
resolved
to
be
fixed.
You
know
open
issue
and
so
on.
Not
surprisingly,
the
quick
working
group
and
the
hdb
working
group
have
had
extensive
involvement
with
martin
and
mark
and
there
is
very
successful
ways
of
using
them.
A
So
having
gotten
all
the
administrivia
out
of
the
way
any
questions
or
comments
or
things
people
want
to
say
I'll,
stop
sharing.
So
I
can.
G
I
do
have
a
process
question
for
those
of
us
actually
coming
from
the
itf.
The
mere
existence
of
the
working
group,
especially
with
the
doomsday
condition
in
its
charter,
is,
is
a
strong
incentive
to
generate
standards
and
the
kind
of
mistakes
we
can
do
in
ipsec
may,
for
example,
if
we
create
a
few
useless
apis,
it's
a
small
industry
that
gets
the
damage
if
we
create
a
bunch
of
useless
http
api
standards,
it's
much
bigger
damage.
G
So
my
question
is:
do
we
have
any
additional
processes
in
mind
to
ensure
that
there
is
actually
what
concerns
us
before
we
adopt
or
before
we
standardize
things.
A
That's
a
really
good
question
I'll
defer
to
barry
for
commenting
on
that.
A
C
Very
handy
tab:
yaran.
Can
you
just
repeat
the
last
bit
of
your
question.
G
So
my
question
is:
we
have
a
strong
incentive
to
actually
generate
standards
and
since
the
industry
in
this
case
is
so
big
diverse,
but
just
big,
we,
we
have
a
large
potential
of
doing
damage.
So
my
question
is:
do
we
have
a
special
processes
in
this
group
to
ensure
that
we
actually
do
have
wide
consensus.
C
E
I'd
say
that
the
the
risk
of
doing
actual
damage
is
fairly
small.
I
think,
unless
you're
considering
damage
to
the
ietf's
reputation,
which
frankly
gets
damaged
in
this
fashion
on
a
nearly
daily
basis.
I
personally,
I
that
I
think
is
it
still
drives
a
large
part
of
the
challenge
we
face
in
that
we
have
a
relatively
short
amount
of
time
to
make
sure
that
this
community
is
sufficiently
representative
of
the
industry's
needs
that
we
can
actually
do
work
that
moves
the
needle
that
actually
helps
and
doesn't
get
ignored.
E
I
personally
will
be
objecting
to
adopting
documents
that
I
don't
think
can
do
that
that
that
don't
seem
to
get
traction
with
practitioners
and
implementers,
or
at
least
don't
seem
like
they
could
and
that'll
just
be
my
personal
view.
I
would
hope
that
a
few
other
people
do
that
too,
and
we
can
try
and
drive
some
quality
here,
but
yeah.
A
A
So
thanks
all
for
putting
up
with
all
this
beginning
roberto,
you
want
to
ask
to
share
and
let's
try
to
you
know,
present
the
general
topic
and
we
have
half
an
hour
for
five
documents.
So
that
means
you
have
like
four
or
five
minutes
to
talk
about
each
one.
A
Yeah
no,
I
should
have
oh
okay.
H
A
F
F
So
once
them
well,
eric
launched
mark
launched
the
pool
and
it
was
positive.
Now
the
specs
have
roughly
one
year.
They
are
configurable
in
redacry
scale,
kong
and
by
proxy
azure
api
gateway.
They
are
supported
by
italy
and
the
netherlands.
More
other
countries.
European
countries
which
I'm
in
touch
with,
are
going
to
implement
this,
just
like
a
the
uk
and
some
apis.
F
So
those
are
so
much
some
of
the
headers
we
had
to
want
to
replace
and
on
the
right,
the
simple
set
of
values
so
just
express
the
the
the
squad
units
for
the
total
limit,
the
number
of
remaining
units
you
have
and
then
the
reset
time
of
the
quarter
in
delta
seconds,
just
like
retry.
F
After
so
we
have
the
same
semantic
for
both
when
you
are
in
four
to
nine
and
when
you
are
with
limiting
so
in
this
slide
seems
complex,
but
just
ignore
the
part,
the
optional
part
on
the
left.
It's
actually
a
comment.
F
You
just
have
to
process
the
mandatory
part,
but
if
you
want
you
can
express
all
other
multiple
rate
limiting
policies
with
the
number
of
seconds
at
the
number
of
a
quarter
units
and
the
window.
F
So
in
this
case
we
have
10
calls
every
five
seconds
and
I
have
one
cap
of
80
requests
in
60
seconds.
All
the
this
optional
part
should
not
be
interpreted
by
the
the
client,
it's
just
to
communicate
a
wider
context
of
the
rate
limit,
so
it's
optional,
so
technical
choices
we
just
support
delta
seconds
just
like
we
try
after
this
prevents
issues
with
ntp,
skew
and
adjustment
issues.
F
Moreover,
when
you
use
timestamp,
you
need
a
synchronization
between
clients
and
server.
The
quota
is
expressed
in
units.
It
may
or
may
not
be
requests.
We
want
to
standardize
the
the
syntax
and
we
want
to
give
implementers
a
bit
of
flexibility
in
implementing
their
their
quota.
So
you
have
flexible
semantics
to
express
dynamic
policies,
sliding
windows
and
concurrency
limits.
F
That
depends
on
which
values
you
feel
the
fields,
and
we
don't
mention
infrastructure
concepts
like
connection,
because
a
service
can
be
built
with
a
wider
infrastructure,
and
it's
thanks
to
the
experience
of
alex
that
works
with
the
red
hat
api
gateways
and
there's
a
lot
of
experience
in
deploying
larger
large
architectures
with
large
api
architectures
of
an
issue
needing
input.
Well
after
one
year
we
have
some
implementers
so
well.
We
can
try
and
change
everything,
but
I
think
we
should
find
a
way
to
respect
the
actual
ecosystem
that
that
exists.
F
Actually,
so
we
can
move,
but
we
should
move
with
a
bit
of
sensible
a
bit
sensibly,
so
refined,
normative
language,
respect
to
intermediaries,
use
of
structured
headers,
whether
we
want
to
or
not
to
define
a
torturing
scope.
There
was
a
discussion
even
with
the
mark
and
roy
other
issues
that
may
not
be
worth
investigating,
define
header
dependencies
and
upper
bound
upper
bound
for
red
limit
reset,
but
what
we
don't?
Those
are
minor
points.
F
So
one
question
everybody
asks
us:
are
you
inventing
a
new
service
management
model?
No,
we
just
want
to
clean
things
up
for
all
the
organization
that
use
them,
so
we
are
not
proposing
something
new.
We
want
to
just
to
reorganize
something
that
exists
for
organizations
that
already
use
them.
This
is
an
existing
use
case.
We
want
to
mix,
standardize
it
and
we
are
not
advocating.
F
This
is
the
best
way
of
throttling
right,
limiting
connection
whatever,
and
why
don't
you
use
timestamps
because
well,
I
said
before
time
stamps
require
ntp
on
both
sides
and
that
ntp
is
hard
in
the
real
world
and
what
and
we'll
actually
try
after
so
thanks.
That's
all.
I
hope
I
I
have
been
clear
and
quick,
and
I
really
hope
that
this
draft
will
be
adopted,
because
currently
one
of
the
limit
to
the
implement
for
the
implementers
is
that
okay,
it's
cool.
F
We
would
like
to
implement
that,
but
we
are
waiting
for
it
to
be
standardized.
A
F
Know
since
you're,
seeking
that
I
well
I'm
in
the
process
of
other
drafts,
so
I
know
it
can
change
and
I
think
we
we
can
do
whatever
it's
I
mean
the
the
work
group
is
is
master.
Okay.
All
I
say
is
that
I
suggest
doing
that
together
with
implementers,
because
it's
it's
more
sensible
than
just
doing
something
that
won't
get
adopted,
because
people
is
stuck
with
their
previous
implement
implementation
unless
they
are
clearly
a
good,
very
good
reason.
A
Mark
does
anyone
have
it
thanks
daryl?
Does
anyone
have
any
clarifying
questions
that
would
make
their
understanding
of
this
more?
You
know
improve
their
understanding
again.
What
we
want
to
do
is
make
sure
we
understand
the
document
so
that
we
can
decide
in
the
interest
of
time,
probably
most
likely
on
the
mailing
list.
A
We're
not
gonna.
There's
lots
of
discussion
in
the
in
the
chat
about
changes
that
could
be
made
should
be
made
and,
as
someone
pointed
out,
we'll
make
those
after
adoption,
but
are
there
any
any
clarifying
questions.
A
Yet
suggested
we
do
show
of
hands.
Okay,
we'll
do
that,
since
that
work.
A
Before
raise
your
hand,
if
you
are
opposed
or
you're
just
not
ready
to
decide
we're,
not
making
the
decision
here
again
we'll
go
to
the
mailing
list
anyway.
So
if
you're
opposed
please
let
us
know.
F
You
everybody,
I
can
thank
you
close
my
well
thanks
for
to
alex
that
is
in
mute
now,
but
he
made
a
great
work
for
this
on
this
draft.
A
B
A
Yes,
and
and
thank
you
very
much
for
you-
know,
handling
the
time,
okay,
roberto.
No,
I'm
sorry.
A
Can
you
request
screen
access.
A
B
Okay,
go
for
it!
Thank
you
very
much.
Okay,
thanks
very
much
so
I'll
be
presenting
three
drafts
for
adoption
and
the
http
building
blocks
or
http
api
building
blocks
working
group.
Very
briefly
about
myself.
For
those
of
you
who
don't
know
me,
my
name
is
eric.
I've
been
working
in
companies
that
are
selling
api
management
software,
so
my
input
mostly
comes
from
companies
who
are
developing
apis
and
are
looking
for
certain
design
patterns,
so
to
speak
that
they
can
use
an
apis
to
make
it
easier
to
scale
their
api.
B
A
A
A
A
Nothing
yeah,
okay.
He
didn't
have
a
backup
presenter.
B
Can't
hear
me
we
can
now
yeah.
Oh
I
don't
I'm
sorry.
I
don't
know
what
happened.
I'm
really
confused
fact:
okay,
sorry
to
my
apologies,
okay,
so
deprecate
when
when
did
it
stop?
Did
you
see
the
deprecation
slide.
B
B
Very
good,
so
all
the
interesting
stuff
didn't
work.
Okay,
now,
okay,
now
first
draft
api
deprecation.
Can
you
see
that
slide
about
that
draft?
Yes,
okay,
good
thanks,
I'm
nervous
now,
so
that
one
was
developed
together
with
sanjay
delau.
The
motivation
was
to
have
something
that
allows
you
to
announce
that
an
api
is
going
to
be
deprecated
or
it
has
been
deprecated
in
the
same
way
as
the
sunset
header
allows
you
to
say
that
an
api
is
going
to
be
shut
down.
B
When
is
the
shutdown
going
to
happen?
All
of
this?
You
can
link
to
additional
resources
and
that's
the
fundamental
model
behind
it,
the
history,
this
draft
we
started
working
on
it
in
february
2019.
We
have
published
four
versions.
In
the
meantime,
I've
put
all
the
links
here.
All
the
slides
are
online.
You
can
find
them
and
follow
the
links
we
have
a
section
on
implementation
status,
meaning
that
there
are
some
existing
implementations
already.
B
Some
use
the
deprecation
header
field.
Others
use
something
similar,
but
they
use
a
different
concept
because
it's
not
yet
standard,
but
we
do
see
some
uptake,
at
least
in
the
field
where
api
designers
seem
to
think
that
this
is
something
that's
useful,
so
I
think
that's
it
for
the
deprecation
header
field.
I
really
want
to
keep
it
short
and
sweet.
I
A
All
right,
while
waiting
for
eric
to
reconnect,
I'm
sure
he's
about
to.
E
Yeah,
okay,
oh
there's
eric
he's
back.
I
have
been
asked
about
this
draft
from
the
api
people
in
my
employer
and
they
expressed
desire
for
it.
I've
also
heard
from
sanjay
one
of
the
authors
that
he's
talked
to
lots
of
folks
about
it,
so
I
I
think,
there's
definitely
demand
for
this
and
I
think,
there's
a
certain
amount
of
urgency
around
it.
So
I
I
support
adoption.
A
A
Okay,
we
will
move
forward
with
a
call
to
adopt
on
the
mailing
us.
Yes,
I
see
lots
of
support
in
the
jabber
chat.
Okay,
we'll
do
it
at
this
point.
It
seems
I
think
things
are.
People
are
bringing
stuff
up
that
they
already
know
is
of
interest.
So
I
first
want
to
hear
if
there's
people
who
have
objections
julian,
it's
supposed
to
show
our
hands
it's
in
the
interest
of
savings
time,
since
we
will
be
going
back
to
the
mailing
list
for
all
this
stuff.
B
Okay,
extra,
the
the
next
draft
is
a
little
bit
more
complex,
maybe
so
that
is
something
that
I've
been
working
on
with
herbert
from
the
sample.
So
here
the
idea
is
that
there
is
the
web
linking
draft
that
has
been
around
for
a
long
time,
authored
by
mark
updated
in
the
meantime,
and
it
has
basically
defined
how
web
links
work.
It's
something
that
is
really
fundamental
to
many
things.
Nowadays,
what
it
doesn't
allow
you
to
do
is
represent
links
themselves
as
a
resource,
so
we
have
had
various
scenarios
where
that
would
be
interesting.
B
B
B
There
are
some
tricky
parts
around
the
context.
So
when
do
you
use
anchors
and
stuff-
and
I
don't
want
to
go
into
any
details
around
this-
but
we've
carefully
worked
these
things
out
at
least
that's
what
we
believe
here
is
a
very
simple
example,
so
that
would
be
a
json
version
of
of
two
links.
Basically,
both
links
have
an
anchor
link
relation
and
a
target,
and
that's
just
a
simple
json
representation
for
doing
this
kind
of
thing
about
the
history
this
one.
B
Actually,
we
have
started
developing
that
a
long
time
ago
in
december
2016
we
switched
drafts
in
the
in
the
middle
somewhere,
but
in
the
meantime
we
have
actually
we've
gone
up
to
11
draft
versions.
We
tweaked
the
biggest
change
we
did
was
actually
tweaking
the
json
model
to
be
json,
ld
friendly,
because
we
had
some
input
from
communities
that
were
saying
that
it
would
be
nice
if
the
json
would
work
well
with
json
ld.
So
we
went
through
a
whole
redesign
of
json.
That's
where
we
are
now.
B
We
do
have
some
implementations,
so
we
have
implementations
in
library
systems.
We
also
probably
have
a
very,
very
big
upcoming
implementation
and
the
gs1
standard.
They
want
to
use
the
linkset
model
as
well.
Js1
are
product
codes,
so
they
have
a
lot
of
information
about
products,
same
kind
of
thing
you
can
represent
that
with
links,
and
they
have
asked
us
that
they
would
really
like
this
to
become
a
standard
better.
Sooner
than
later,
we'll
see
how
fast
it
goes,
but
that's
the
current
status
that
we
have
there
that
we
do
have
some
interested
parties.
J
Mark
phil
I'll
just
jump
in
if
I
may
hello,
phil
archer,
just
to
back
up
what
eric
was
just
saying
gs1
for
those
who
don't
know
is
this
body
behind
the
barcode.
We
have
one
and
a
half
million
members
around
the
world,
including
all
the
biggest
retailers
and
manufacturers.
We
very
strongly
endorse
this.
J
We
have
a
standard
in
public
review
at
the
moment,
which
has
a
big
section
that
says
the
following
text
is
normat
is
informative,
only
be
only
until
link
set
becomes
a
standard
when
all
the
text
below
becomes
normative
right.
We
really
really
want
this
to
be
an
rfc
we've
already
implemented
it.
We
have
people
like
you,
know
every
healthcare
company
in
the
world
asking
for
this,
so
we
are
strongly
endorsing
it.
A
A
You
should
have
heard
what
they
were
saying
about
you.
While
you
were
gone,
any
questions
clarifying
comments,
alexis.
K
I
just
had
a
quick
look
at
rfc
6690
that
came
out
of
the
core
working
group
and
I
believe
it
already
describes
one
of
the
formats
in
the
draft,
which
is
identical,
but
the
media
type
is
already
registered.
So
I
think
checking
that
this
is
not
duplicating
existing
work,
a
good
thing,
the
json
one
is,
I
don't
believe
it's
registered.
B
Sense,
if
I
yeah
so
the
core
model
is
close.
It's
it
is
not
the
same
model,
so
they
have
tweaked
the
model
for
their
needs.
We
we
looked
at
that
when
we
started
working
on
that
and
we
decided
that
the
core
model
was
not
what
we
needed,
because
they
didn't
take
the
the
real
web
linking
model,
but
instead
they
tweaked
it
in
some
ways
that
they
needed.
B
K
B
Okay-
I
don't
understand
I
will
I
will.
I
will
have
to
get
back
to
you,
because
that
we
we
looked
at
that
a
long
time
ago.
I
can't
remember
exactly
what
the
differences
were.
We
did
find
differences
that
that
made
us
develop
a
new
one
or
made
us
write
this
graph,
but
I
can't
give
you
the
details
right
now.
K
I
A
Okay,
eric,
I
guess
we
will
provisionally
you
know,
take
it
to
the
list
that
we
are
concerned
about
the
reproduction
and
the
duplication
and
the
competing
documents
that
we'll
have
to
resolve
that
and
figure
out.
What
we're
going
to
do
right
sure
is
interested
in
thinking
this
work
is
valid,
so
eric.
Thank
you.
Please
go
on
to
your
last
one.
B
Okay,
move
on
to
the
last
one.
The
last
one
is
called
content
warnings,
so
this
one
is
has
been
worked
on
in
collaboration
with
andre
silik,
and
the
motivation
for
this
one
was
that
when
the
rfc
7807
came
out
about
problem
details
for
http
apis,
that
was
a
that
is
a
rfc
that
you
can
use
to
serve
standardized
error
messages
which
is
very
useful.
It's
it's
used
in
many
apis.
B
Nowadays,
there
was
a
clear
need
for
that,
and
then
the
question
was:
can
we
do
something
about
warnings,
meaning
that
there
is
not
an
error,
but
some
some
condition
was
not
exactly
as
it
should
be.
Is
there
a
way
how
this
could
be
exposed
in
apis
without
having
to
reinvent
that
mechanism
every
single
time?
B
And
what
we
did
is
we
came
up
with
a
model
where
there's
a
header
field
called
content
warning
and
that
header
field
then
signals
that
there
that
the
request
was
successfully
process,
but
that
there
has
been
that
there
have
been
some
warning
conditions
and
there
are
different
ways
how
this
can
be
signaled.
The
draft
proposes
that
there
will
be
a
registry
for
registering
different
kind
of
content
warnings.
B
This
looks
like
this
to
show
you
a
very
brief
example.
So
there's
a
post
and
then
the
response
says
it's
okay,
but
there
are
embedded
warnings
and
then,
in
the
content,
you
see
that
there's
this
specific
structure
in
here
and
this
structure
is
what
is
proposed
in
the
draft.
It's
actually
relatively
similar
to
what
rfc,
7807
standardizes
for
the
error
messages
slightly
different,
but
to
to
give
some
similarities
in
the
models
how
that
works.
B
The
history
of
this
draft
is,
we
started
working
on
it
about
a
year
about
a
year
ago,
in
november
2019
it
we
have
seen
three
draft
versions.
So
far
we
have
worked
on
making
sure
that
we
see
some
implementations.
I
think
for
this
draft.
Definitely
implementation
status
still
needs
to
be
tracked
better.
I'm
not
aware
of
that
many
implementations,
but
we
do
see
some
uptake
and
that's
the
the
last
draft
that
I
wanted
to
present
and
just
to
as
a
summary
right
again
like.
I
have
a
slide
here
where
you
can
find
all
the
information.
A
Wasn't
clear
to
me
that
we
had
as
strong
consensus
for
adoption
here
so
mark's
got
a
hand
yeah.
E
So
we
discussed
this
and
and
the
precursors
to
it
in
the
http
working
group-
and
there
was
the
first
stage-
was
just
reusing
warning,
which
we
felt
was
a
bad
idea,
and
then
he
did
the
content
warning
proposal.
E
But
this
is
one
of
the
things
where
I
think
having
a
separate
working
group
is
useful,
because
that
community
didn't
have
a
lot
of
interest,
but
that
doesn't
mean
it's
necessarily
a
bad
idea.
It
just
wasn't
interesting
to
folks
in
that
community.
E
My
only
question
about
this
is,
you
know
one
of
the
considerations
you'd
make
in
this
sort
of
thing
when
weight
up
the
header
is
whether
it
uses
structured,
headers
and
normally,
I
think,
that's
something
we
can
talk
out
in
the
course
of
working
on
the
draft,
but
because
this
one
is
saying
you
know
up
front.
This
is
a
json
format
in
a
header,
it's
something!
Oh,
it
does
use
sf.
I
thought
it
was
jason.
E
E
E
If
you
want
to
do
logging
with
your
infrastructure
like
a
cdn
or
or
you
know,
envoy,
or
something
it's
a
lot
easier
to
log
a
header
than
it
is
to
log
something
from
the
body,
and
we
do
see
some
pressure
on
people
to
define
new
http
status
codes
because
it's
you
know
they
want
something
they
can
log.
So
I
I
would.
I
think
that
this
would
be
an
interesting
thing
to
have,
and
I
don't
see
how
it
could
be
harmful
if
it
doesn't
get
an
option.
It's
just
another
header
that
doesn't
get
used.
I
But
I
I
think,
if
I
understand
correctly,
that
you
wouldn't
actually
log
what's
in
the
header,
the
header
is
just
a
signal
to
go.
Look
in
the
body
to
go
and
say:
oh,
there
is
a
warning
in
this
body
and
therefore
you
ignore
all
bodies
that
don't
have
a
content
warning
header,
but
then,
if
there
is
a
content
warning,
then
you
go
into
the
body
to
go.
Looking
for
the
warning,
am
I.
J
E
Right,
but
from
what
I
saw
in
the
example,
there
was
an
identifier
for
the
warning
in
the
header,
which
is
what
you'd
grab
on
to
I
mean
you
can
say
you
can
tell
that,
there's
a
warning,
the
body
just
from
the
the
media
type
already.
If
you
just
wanted
to
know
whether
or
not
there
was
a
warning
there,
there's
a
media
type
defined
for
problem
details.
H
Yeah
that
gets
in
and
around
one
of
the
questions
that
I
had
had
so
is
the
pictured
usage
of
this
exclusively
for
jason
documents.
So,
like
would
it
be
possible
to
have
it's
not
clear
to
me
from
reading,
at
least,
but
what
we
have
now
that
the
scope
of
this
covers?
You
know
if
someone's
returning,
xml
cbore
mp5,
whatever
that
it
would
be
you.
It
would
be
usable
to
have
this
content
warning
as
part
of
that,
because
there
would
be
nowhere
to
necessarily
to
put
to
put
the
warning.
B
A
Yeah,
so
I
would,
I
would
say
that
we
need
some
more
discussion
and
and
scope
it
like
chris
was
saying
we
won't
explicitly
call
for
an
adoption
yet
okay,
so
I
I
think
by
all
accounts,
we've
had
a
very
successful
first
meeting,
I'm
going
to
end
with
thank
you
to
braun
for
taking
notes
very
extensive.
I
encourage
people,
I
just
posted
the
link
there
in
the
chat
room.
It's
also
in
the
agenda.
Take
a
look
see
if
there's
any
corrections
you
can
post
them
to
the
list
and
so
on.
A
Thank
you,
braun
appreciate
it
and
also
your
involvement
in
the
jammer
room
thanks
to
daryl
the
presenters
one
last
call
for
action
is
our
manager
sometimes
say
is
you
know,
go
out
and
tell
your
colleagues
that
this
group
exists
and
that
you
can
just
participate
in
the
mailing
list
and
the
github
once
that's
set
up,
which
we
will
announce
in
the
mailing
list.
A
So
thank
you
I'll
say
enjoy
the
rest
of
the
week,
but
that
means
enjoy
the
next
session.
If
you're
going
to
any
and
we'll
see
you
online
and
hopefully
in
person
soon,.
E
You
hey
rich
yeah,
do
you
want
to
maybe
grab
daryl
and
care
about
github,
real,
quick.
A
Yeah,
you
know
what
let
me
mess.
I
don't.
A
You
know
we
were
he
and
I
were
actually
he
and
I
were
actually
gonna
chat.
Can
you
do
webex
sure
all
right?
Let
me
let
me
send
you
the
link
cool,
you
know
how
to.
A
Yeah
yeah
good
point:
okay!
Let
me
yes
all
right:
okay,
yep
great.